Three Better Ways of Doing Networking That We Ain't Doin'

The best networking ideas are ready to go, but collecting dust.

I really enjoy tweaking things to squeeze just a bit more power out of what I already have. If I am building a small-block Chevy engine, over-clocking a server, reprogramming a EEPROM or trimming out a fishing lure, I love pushing stuff to its absolute limits.

However, sometimes all the modding in the world just can not solve the core problem. Putting a .265 duration cam, rollers, headers and hi riser will improve the suck factor of 305 Chevy very little.

It's time to scrap the crap and move up to the next big thing.

All too many times in networking we are patching protocols, transports, etc., that were designed for networks nearly 30 years ago. Here are three things that we could do and should do to improve security, scalability and the overall network in general. One that is ready to go, one that is something to look for in choosing gear, and one that is an up-and-comer.

Exhibit 00x01: Stream Control Transmission Protocol

Wouldn't it be great to have all the advantages of UDP with the ordered data delivery of TCP? With an IETF approval of RFC 2960 in October 2000, SCTP burst on the scene as a protocol for VOIP with the side benefit of solving TCP problems like half-closed connections, SYN vulns, head-of-line blocking, etc.

PLUS, SCTP added many awesome features like multistreaming, where I can have multiple independent streams so data is delivered based upon an associated stream. Cool stuff like system backups and/or mirror site downloads as well as apps that are multiplexed like VOIP, text, and video that our independent data streams over a single end-to-end connection is easily accomplished with SCTP multistreaming. Versus multiple open TCP connections, one for each stream eating up CPU cycles, memory resources, etc.

SCTP is available on the Linux 2.6 kernel and Cisco IOS. I have tested it and it works great! Wanna learn more? check this out.

Exhibit 00x02: IPv6

Yeah, yeah, yeah - the Internet has been running out of IP addresses for the past 100 years. Seems like every time I read a trade rag the full depletion of IPv4 address occurs more often then furniture stores go out of business. We've cried wolf too much on this one. Be that as it may (I have always wanted to use that statement) IPv6 is really cool and offers many benefits, but getting there is not easy.

As proof, I offer this great blog entry from the mega brains at Breaking Point Labs on their attempts to realistically deploy IPv6.

The real issue with IPv6 is in hardware lookup time in the router. IP address lookup is THE performance bottleneck in many routers. Many routers are handling IPv6 lookup like they do a 32-bit IPv4 lookup and that dog just don't hunt. What is needed is a better lookup method like Fast IP Lookup as proposed by the IEEE. Consider that a IPv6 address is 4x the size of IPv4 address in terms of both size and CAM table space.

We need to use a method similar to searching a database: a hash algorithm. Then we add a dedicated Content Addressable Memory (CAM) to deal with lookup collisions to prevent lockup. IP Lookups are based upon a cycle hit rate and expressed in terms of a percentage. For example, my success rate of a positive IP lookup with one ASIC cycle is 98.22% The better the percentage rate the better performance I get from my router. IPv4 hit rates are normally high, but test it again with IPv6 and watch it crumble.

The whole point of this is to bring to your attention that many vendors talk an IPv6 game; however, they are playing with IPv4 helmets/shoulder pads. If you are looking at deploying IPv6 at all, double check how your chosen vendor does IPv6 lookups based upon a first-cycle hit rate. A good rule of thumb is 93% hit rate with 32K entries on one ASIC cycle.

Exhibit 00x03: BIC/CUBIC TCP

TCP is an easy target to beat up on in networking protocols. Just keep in mind that it was designed for an earlier era when error rates were higher and speeds were much slower. That is the key problem with TCP. As TCP receives successful notification that it received the packets, it slowly increases speed; if it loses packets then it cuts the speed in half.

With an estimated 90% of traffic being TCP this really gets to be a huge burden with higher speeds. Achieving optimal speeds with TCP can take sometimes an hour. BIC TCP can achieve optimal speeds in seconds.

It does this by conducting a binary calculation comparison on the minimum window size as compared to the maximum window size. As transmission begins, the window size difference is huge, so the TCP window grows very fast. When a packet is dropped the binary algorithm adjusts the size to the previous window size before the drop. Then the binary algorithm continues adjusting the window size to decrease the overall difference between the minimum and maximum packet size.

BIC has been updated to CUBIC which adds a important time component. CUBIC does not rely on TCP ACKs but that last congestion event. This also helps to make it independent of Round Trip Time (RTT) so its fairness to multiple flows is much better. There are a few other competing TCP options to CUBIC like High Speed TCP Low Priority (HSTCP-LP), High Speed TCP (HSTCP), Hamilton TCP (H-TCP) which is very cool also, Scalable TCP (S-TCP) and a few others as well.

It's fishing time here in Wisconsin and I just tricked out a Mega Bass lure with fiber optic eyes and a adjustable tongue for depth control. If I had a fishing version of BIC (Bass Immediate Catching?) that would adjust the fish size according to my buddy's catch....

Jimmy Ray Purser

Trivia File Transfer Protocol
Legally speaking, foreign governments can spy on one another inside the United States but they can not spy on actual citizens of the United States.

• LANs / WANs
• Cisco
• Jimmy Ray Purser
• networking