Day 2 of Tech Field Day was powered by Starbucks.  Starting off at the hotel with a visit to the Starbucks counter was a no-brainer, but upon arrival the wonderful HP Executive Briefing Center in Cupertino, CA, the Holy Grail of caffeine addicts was discovered – a self-serve Starbucks espresso machine.  As such, many fabulous Dirty Chai drinks were consumed during the day, which may have led to my perking up and asking more questions during day 2.  Maybe that, or we finally got to the networking part that I knew a little more about.  I’m still blaming the Dirty Chai, though.

Netex was first on deck.  And they nailed it.  Not necessarily their message, but their presentation.  They kept their message short.  They had a hands-on example that kept us awake first thing in the morning.  They tempted us with beer.  They didn’t talk longer than they needed to and left plenty of time for questions.  And they still got done early.  Spot on, guys.  I’ll go on record as saying that it’s not necessary to fill your entire presentation with talking.  You need to leave some time for questions that might come up during the presentation as well as questions at the end after you’ve delivered your message.  The reason there are time constraints on presentations is to keep people from rambling on forever.  I don’t mind staying five or ten minutes extra so long as the reason for the overtime was due to a lot of good questions.  At the same time, only leaving two or three minutes at the end of a two hour slide deck due to constant chattering isn’t going to make any friends.

Netex revolves around a product called HyperIP.  HyperIP is a virtual machine that does something rather interesting.  It attempts to fix the TCP message window / global synchronization issue by avoiding it.  For those not familiar, TCP like to increase the window size as data begins transmitting so as to use the link in the most efficient manner.  However, eventually TCP will saturate the reciever with data and the reciever will ask the sender to back off.  TCP does this by backing down halfway, then ramping up again as the sender catches up with the data stream.  Imagine reading me a list of numbers over the phone.  You may start out by reading groups of 3 numerals, then as I get comfortable you may move to groups of 5 then 6, constantly increasing the amount of numerals per group.  Eventually, I’m not going to be able to remember all the numerals in each group, so I’m going to ask you to stop and go back to groups with smaller numerals.  In TCP we try to fix issues like this with things such as Weighted Random Early Detection (WRED).  WRED tries to avoid forcing the sender to back off totally by instead dropping less critical packets in the stream and making these be retransmitted later.  As such, the TCP window size can be kept as large as possible for as long as possible to allow the maximum amount to data to be transmitted in the most efficient way possible for a given link.  It should be noted that WRED only works on TCP due to the ability of TCP to retransmit lost packets due to TCP acknowledgements.  UDP can’t use WRED since these packets would be lost and never retransmitted (more on this in a minute).

HyperIP acts as a gateway for your server devices.  Instead of your backup server pointing to the WAN router, it points to the HyperIP VM.  The HyperIP VM then terminates the TCP stream and “caches” the data.  It contacts another HyperIP VM at the destination site and negotiates the most efficient window size.  It then transmits the data between sites using large UDP packets.  The analogy they used was that instead of transporting individual bottles of beer, the bottles were packaged into”kegs” and transported more efficiently.  When I asked how the HyperIP VMs dealt with packet loss since UDP is not tolerant of packet loss.  I was informed that the HyperIP system kept track of the UDP packets on both sides in a kind of lookup table, so it one was missed it could be retransmitted.  Once the UDP packets arrive on the other side of the WAN link, they are transmitted via TCP to the destination server.

The current use case to me seems to be for backup traffic or other large, bursty types of communication.  Netex admitted that this technology won’t do much for smaller conversations, such as HTTP traffic.  It also only affects TCP, UDP, and ICMP, so more esoteric protocols are out (sorry AppleTalk users).  I’m having an issue with the way HyperIP actually does it’s job.  It seems to me like they are re-inventing the wheel and trying to accomplish something that Network Cool Guys can accomplish with proper QoS design.  In fact, the traffic patterns shown in the presentation after the application of HyperIP look an awfully lot like the traffic patterns after you apply WRED to a WAN link.  HyperIP does have the ability to add some compression to the data stream, so there is the opportunity to reduce the amount of data being sent.  For those that might be using some basic QoS on slow links already and might be thinking about implementing a HyperIP setup, be sure you are classifying your VoIP traffic as finely as possible by using DSCP marking at the source or marking it by protocol / port.  I’d hate to see your priority queue fill up with HyperIP kegs and starve out the CEO’s conference call.

I can see a use case for HyperIP in situations where your company doesn’t have a QoS-focused technical person but has a lot of depth in the server admin area.  Matthew Norwood even called it “QoS for the Less Fortunate”.  I’m not saying that it’s not a fine product or that it doens’t have it’s uses.  I’m just saying that it can’t do anything for me that I can’t do already from the CLI.  But, try it out yourself if your curious.  There should be a 30-day free trial available by the end of February.  Just remember that you’re going to need to buy your VMs in pairs to make the work properly.

If you are interested in learning more about Netex and their HyperIP offering, head over to their website at http://www.netex.com.  You can also follow them on Twitter as @HyperIP

Tech Field Day Disclaimer

Netex was a sponsor of Tech Field Day 5, and as such was partly responsible for my airfare and hotel accommodations.  In addition, they provided a 1 GB USB drive containing information about their product, as well as a bottle opener.  They also may or may not have allowed us the use of their practical example, which consisted of an ice chest filled with cold Corona beer.  I can neither confirm or deny that these beers were consumed by the pool at the hotel after the end of Tech Field Day, day 2.  Netex neither asked for nor were they granted any consideration for this article.  The opinions and analysis expressed herein are mine and mine alone.