In a recent article for the IEEE's Spectrum magazine, Dr. Lawrence Roberts explains how the large routers that power the core of today's Internet are doing it all wrong. They spend too much time processing each packet individually, then storing packets in a queue for during peak loads. This buffering makes VoIP calls and video streams stutter, and these routers use lots of hot-running and expensive memory, and they're stuffed with specially-created chips.
Roberts' company Anagran has a different approach: only do the expensive work for the first packet in a flow, then treat subsequent packets in the same flow just like that first packet, doing away with queues and specially-designed chips in lieu of simple processors and cheap DRAM. (In the late 1960s, Roberts led the team that created the ARPANET, which would morph into the Internet that we know today in the following two decades.) As an added benefit, slowing down flows that go too fast can now be done with precision, rather than bluntly as in today's routers.
Upon reading Roberts' article, the claims look rather extraordinary. Could it be that Cisco, Juniper and the other router vendors have been barking up the wrong tree for decades? In a word, no. Cisco has used numerous different router designs, including several that were fully or partially flow-based. Other vendors have built flow-based routers, too, such as Riverstone. For a while, there were also two-part multilayer switches, where a router would look at the first packet in a flow and then instruct a separate switch on how to switch packets belonging to the same flow.
A flow is defined as all the packets sharing the same source and destination addresses, the same protocol (such as TCP or UDP), and the same source and destination port numbers. But dealing with flows rather than individual packets won't solve all problems. First of all, some packets aren't TCP or UDP, so they don't have any ports. This means that all the traffic in a VPN connection or all IPv6 packets encapsulated in IPv4 packets are treated as a single flow.
The second problem is the supported number of flows. Roberts mentions four million flows. That's a lot. But what if a new application suddenly starts using many more flows than today's applications? It's happened before: first with Netscape, which would set up several new TCP sessions at the same time to download a web page's images faster, then again with BitTorrent, which tries to download from many places in parallel.
Last but not least, managing new flows can be a big problem if there are too many of them.
Dr. Lawrence Roberts
An example of the third problem was the Slammer worm that almost brought down the Internet in early 2003. My experiences back then were that routers which treat every packet individually didn't have much of a problem, but routers that depended on the existence of (somewhat) long-lived flows all melted down. The problem was that this worm fit in a single packet, and an infected host would send out as many as 15,000 such UDP packets per second—where each of those packets was a new flow. The hard/software that updates the flow tables simply can't keep up with such a large number of new flows every second.
Roberts also mentions that he does away with queues. Upon reading his much more detailed whitepaper, it turns out that's not exactly true: there are still output buffers for 20 packets, and it's only the input queues that are no longer necessary. However, on most modern routers, input queues rarely (if ever) build up because packets can be processed as fast as they arrive.
The real problem is that many router vendors still build in large amounts of output buffer space so that queues can build up when the router receives more packets on its inputs than it can transmit on its outputs. Packets are delayed when queues build up, and eventually when a queue reaches its maximum size, packets have to be "dropped" until the queue shrinks again. Flows that suffer from delay or jitter (variation in delay), such as VoIP and streaming, get punished by the queueing. More flexible flows are slowed down significantly when two or more of their packets get dropped.
Roberts' solution avoids this by simply not letting queues build up and tracking how much capacity each flow uses. The fastest-flowing flows are then "punished" by having a packet dropped, which slows them down. This looks like a very promising approach to provide quality of service (QoS) so the Internet can more easily carry real-time traffic such as VoIP. (It's less appropriate to use this mechanism for progressive downloads used by services such as Youtube that also need a certain minimum for fluid playback, but aren't satisfied with a fixed maximum.)
Tracking flows also allows Anagran's routers to detect peer-to-peer traffic reliably without deep packet inspection (something he told us about last year). From the company's whitepaper:
Anagran has found in testing these techniques in an office environment, that P2P users can be identified with high accuracy if during any four second period the user has more than 5 flows and more than 50 Kbps of traffic.
This allows ISPs to address fairness issues between peer-to-peer and regular traffic while maintaing user privacy.
It looks like Roberts has an interesting approach to QoS, but many of the other claims seem overly broad. It's almost certainly possible to build a more traditional DRAM-based router with only 20 output buffers, which would also be cheaper and run cooler than many existing routers. This would probably require some compromises, but so does Roberts' solution.
Too bad, though, that Roberts and/or Anagran aren't participating in the Internet Research Task Force's Routing Research Group (mentioned at the end of the Spectrum article) that is trying to come up with new ways to solve the cost/heat/speed wall that we seem to be approaching.