New Router Manages Flows, Not Packets 122
An anonymous reader writes "A new router, designed by one of the creators of ARPANET, manages flows of packets instead of only managing individual packets. The router recognizes packets that are following the first and sends them along faster than if it had to route them as individuals. When overloaded, the router can make better choices of which packets to drop. 'Indeed, during most of my career as a network engineer, I never guessed that the queuing and discarding of packets in routers would create serious problems. More recently, though, as my Anagran colleagues and I scrutinized routers during peak workloads, we spotted two serious problems. First, routers discard packets somewhat randomly, causing some transmissions to stall. Second, the packets that are queued because of momentary overloads experience substantial and nonuniform delays, significantly reducing throughput (TCP throughput is inversely proportional to delay). These two effects hinder traffic for all applications, and some transmissions can take 10 times as long as others to complete.'"
Re:This isn't new (Score:3, Informative)
Definitely not new.
"The router recognizes packets that are following the first and sends them along faster than if it had to route them as individuals."
Where have I heard this before...oh hay...
http://en.wikipedia.org/wiki/Cisco_Express_Forwarding [wikipedia.org]
Puffery by a startup (Score:5, Informative)
The main players in the routing industry have been working on flow-aware routing for years.
(I'm in the hardware side of our company so I'm not sure where how many and which of the features built on the flow-based architecture are already in the field. But I'm willing to bet a significant chunk of change that that the full bore will be deployed on more than one name-brand company's product line and be the dominant paradigm in routing long before these guys can convince the telecoms and ISPs to adopt their product. No matter how many big names they have on staff - or how good their box is. Breaking into networking is HARD.)
Re:This does not solve the problem (Score:1, Informative)
Routing doesn't even concern itself with TCP. TCP issues such as windowing & acks are a host to host concern.
There are some advanced QoS features on routers that will send an explicit congestion notifications to hosts if their tcp flow is in a class that's exceeding it bandwidth. The end hosts are supposed to back off their transmission rate without all the missed ack, window shortening, and retransmissions that would otherwise be involved if traffic was dropped. That's about as gracefully as a router can deal with congestion for a tcp flow. Of course the end hosts need to support ECN for this to work.
The thing is though, QoS policies are the antithesis of the net neutral / traditional best effort internet.
Re:This does not solve the problem (Score:1, Informative)
Doesn't WRED (Weighted RED) already do this?
Re:Net neutrality anyone? (Score:5, Informative)
That an ISP may prioritize services like VOIP over http or bittorrent is not what net neutrality is about and quite frankly is something that a good network engineer would look into and would probably implement.
Whats the date on this, 1998? (Score:1, Informative)
Someone put the spades back. flow routing is SUCH old news... How the heck did this make slashdot?
Re:This does not solve the problem (Score:4, Informative)
This has already been addressed in the IP specs: ECN [wikipedia.org]
One of the big problems with getting ECN adopted has been that Windows hasn't supported it. Vista does and I haven't seen anything specific but I'm reasonably certain that Windows 7 does as well. MAC OSX 10.5 supports it as well. Linux has supported it for quite awhile. It's usually disabled by default, so that may be an issue in getting it widely supported. But the issue isn't that we don't know how to do it better. It's just overcoming the inertia.
This Design is Flawed (Score:3, Informative)
Wrong (Score:3, Informative)
"TCP throughput is inversely proportional to delay"
Absolutely wrong, 2Mb/s at 1ms delay gives the same throughput as 2Mb/s at 10ms delay
As long as the window is large enough
Re:This isn't new (Score:5, Informative)
I'm hesitant to say he's full of shit without hearing a bit more of the debate around his ideas.
There really isn't a debate around his ideas, at least not any more.
The hitch is management overhead. Managing a flow requires remembering the flow. That means data structures and stateful processing. It's expensive and no one has demonstrated hardware accelerators that do a good job of it. On the other hand, devices like a TCAM can accelerate stateless packet switching a couple orders of magnitude past what's possible with a generic PC.
At low data rates where DRAM latency is not an issue (presently around the 500mbps range), flows can work and accomplish much of what he claims. At higher data rates (like the 10-100gbps links on the backbone) we simply can't build hardware capable of managing flows for any kind of reasonable price.
Beyond that, Larry has really missed the boat. The next routing challenge isn't raw bits per second. That's pretty much in hand. Rather the next challenge is the number of routes in the system. If you want two ISPs for reliability (instead of one), you currently have to announce a route into the backbone that is processed by every single router in the backbone even if it never sees your packets. That currently costs about $8k per route per year, the cost is falling a lot more slowly than the route count is climbing and the lack of filtering and accounting systems mean that each one of those $8k's is an overhead cost to the backbone networks rather than a cost directly recoverable from the user who announced the route.
Flow based routing doesn't help us solve that challenge in the least. If anything, it makes it worse.
If you're interested in routing theory and research, I recommend the Internet Research Task Force Routing Research Group (IRTF RRG). They're chartered by the IETF to perform basic research into Internet routing architectures and anyone interested can participate.