New 'flow router' may save the Internet from collapsing under the weight of all your v-blog posts
By Joseph L. Flatley 
posted August 10th 2009 4:22PM
posted August 10th 2009 4:22PM
The prospects of a Future Inevitable Internet Collapse™ has some of our readers seriously freaked out. You know the type -- they live in places like Idaho and Montana, in fortified mountaintop retreats, where they hoard digital media like it was canned food in December 1999. And concerns over bandwidth aren't limited to a lunatic fringe -- no less august a publication than IEEE Spectrum has recently posted an article by Lawrence G. Roberts (who pretty much helped invent the modern router) in which he discusses the state of the Internet. According to Roberts, our current routers are still designed to handle much smaller amounts of data than they are currently pushing. Streaming data only works at all, he says, due to extreme over-provisioning -- "Network operators," he says, are throwing "bandwidth at a problem that really requires a computing solution."
One possible solution is something called "flow management." Instead of routing each packet individually, a flow router attaches an ID to each packet in a specific stream ("flow"). After the first packet is routed, each subsequent packet with the same ID is sent along the same route -- cutting down on time and on the amount of lost packets. Roberts' company, Anagran, has one such device on the market now -- the FR-1000, which he says consumes one fifth the power of a comparable (traditional) router, one tenth the space, and should reduce operating costs in GB/s by a factor of ten. And this, dear readers, may be the key to the survival of the Internet -- that is, until the robots get us.
One possible solution is something called "flow management." Instead of routing each packet individually, a flow router attaches an ID to each packet in a specific stream ("flow"). After the first packet is routed, each subsequent packet with the same ID is sent along the same route -- cutting down on time and on the amount of lost packets. Roberts' company, Anagran, has one such device on the market now -- the FR-1000, which he says consumes one fifth the power of a comparable (traditional) router, one tenth the space, and should reduce operating costs in GB/s by a factor of ten. And this, dear readers, may be the key to the survival of the Internet -- that is, until the robots get us.
Thank GOD!
M1st
huh?
Did you just say...
M*1st*
Burn the witch!
Zoom on the picture and see:
'it can selectively discard packets to protect web, voice and video while limiting peer-to-peer flows'
Well guess what? I prefer peer-t-peer over freakng youtube and idiots falling for MPAA schemes where you pay like mad for stupid movies that have no sibstance, and web doesn't need protecting because it's limited traffic anyway.
Also all those ID's and hashes make it that more easy to 'manage' us and identify and control everything in the negative sense.
I was just thinking about this 2 days ago when engadget posted an article about that concert being streamed for iphone. There was a mention of the strain that would be put on the local service provider's system, and I started to think about how much less efficient it is to send out millions of streams of a live broadcast rather than simply sending out one signal, the old fashioned way (like regular old tv).
Certainly this isn't the solution for many situations, but when Many users are attemting to access the same data at once, it makes perfect sense.
"...and I started to think about how much less efficient it is to send out millions of streams of a live broadcast rather than simply sending out one signal, the old fashioned way (like regular old tv)."
Yeah, it's called IP multicast and its been around for a looong time.
And it's totally different from what this is talking about.
I never believed in the bandwith myth just like I don't believe in the swine fly epidemic myth.
"swine fly epidemic myth. "
Yeah, I'll believe that one when pigs fly ...
Its fun to watch "new" data transmission technologies circle between traditional synchronous and asynchronous philosophies. Just like that nickel you watch spin down those coin funnel donation boxes.
According to the article, the principal benefit of flow routing is limiting the amount of P2P traffic that any given router has to handle. I don't think that filtering traffic is the only way to save the internet.
Flow switching has been around for over a decade now. The first incarnation of it I came across was cisco multi-layer switching which was quickly replaced by CEF. I have no idea why this article received publication. Even the comments of the spectrum article are all 'so what?'
I think the only big thing here is that they're combining CEF and NBAR so you're tagging the flows for filtering in addition to just routing by flow.
But again the question is "So what?" It's obviously already happening, just ask the Comcast users who have their P2P traffic rate-limited.
I was just thinking the same thing! Sounds just like MLS! WTF?
This does sound pretty cool. I guess we users won't see the benefit of it until our favorite websites pick it up. Or is it the ISP's who need to own it? Either way, it would be a big benefit to watching TV on PC.
it is like the Flow Condenser?
Flux Capacitor
Forget flow control. What you need is a fabric so that multiple paths can be taken SIMULTANEOUSLY between two points...Only one company working this arena right now and is patenting their wares as fast as possible:
http://www.raptor-networks.com
"...The force is coming..." lolwhat?
Jesus their website is hideous.
The tech fails. it drops packets still.
Finally a solution! Senator Ted Stevens can finally rest soundly.
http://www.youtube.com/watch?v=_cZC67wXUTs
This is old...
We currently use this technology... we call MPLS (multiprotocol label switching). It's the best solution for the bandwidth problem. All the big networks use this, ISP, carriers cores, etc.
So don't worry ;) Telecom engineers are ready for this ;)
lol a blog is making fun of how much people blog
Old technology! Haven't you heard of MPLS? All backbone routers from network operators run just that! Looks like someone is trying to sell their old router. :)
Minneapolis, MN?
Actually it's somewhat ironic, but many modern routers actually incur additional overhead when doing MPLS lookups vs straight IP lookups. For example, the iconic Cisco 6500/7600 series that powers a large amount of the Internet has a 33% overhead (bringing centralized lookup capacity down from 30Mpps to 20Mpps) when doing an MPLS lookup. The "do the lookup only once at the edge then tag the packet" reason behind MPLS' initial development was a 1998 era problem which has since been totally eliminated. The reason people use MPLS today are:
1) Traffic engineering (since you can dictate the entire path at the ingress point, and allocate LSPs onto paths with available bandwidth).
2) Converged data transport over the same infrastructure as your IP network.
3) Faster failover response, since MPLS lets you "pre-calculate" a backup path for every possible link and node failure and push that backup path into your routing hardware. That way, when a fiber gets cut or a router blows up in your face, every router doesn't have to scramble to calculate a backup, it already knows exactly where to go.
@humble226
Don't forget about the ability to handle multiple networks with overlapping IP address spaces.
Hopefully we can put an end to that silliness with IPv6.
Hey, I live in Montana and I'd care about a future Internet collapse if I could get any decent bandwidth to begin with...
This is total crap, flow based routers like this were an early shortcut to higher speeds back when longest prefix match lookups in hardware were hard, but they carry significant drawbacks and have no place on the modern Internet. The biggest problem is that while they work well under "normal" traffic conditions, they fail miserably in the face of large numbers of flows. For example, when the Slammer worm came out everyone running flow based routers (Extreme Networks being the biggest thing on the market that did this) had their networks blow up in their face because of the random destination traffic of the worm scanning for new hosts. Engadget, stick to cell phones please. :)
Engadget is just reporting on the article in IEEE Spectrum.
so they just make Yellow became smaller while Green ones grow bigger?
.
genius!
So it drops the yellow ones down into that chute. Eventually, won't the pile of yellow ones become big enough to clog up everything else?
Riverstone did this 15 years ago- from one of their last users guides-
"When an RS port receives a packet for routing, it matches the packet’s flow against those found in the L3 flow table.
• If a match is found, the packet is forwarded to the exit port and transmitted.
• If a match is not found, the packet is forwarded to the CPU and the destination is looked up in the
Forwarding Information Base (FIB)."
In addition, they were amongst the first to use ASICs in routing (equivalent to today's CEF in Cisco.)
Sigh, this man was the first to invent the internet, but then he took a long nap.
CEF actually has nothing to do with hardware forwarding, it has to do with making every routing lookup perform the same for any destination. The example you cite shows the previous behavior, you had a "fast path" (or cache, essentially) and a "slow path" (cpu processed longest prefix match). If the destination had never been seen before, the first packet had to go to the slow path CPU, then the results would be added to the fast path. CEF introduced the concept of a dedicated forwarding data structure called a FIB, which was pre-populated with all of the routing table, so that all lookups behave the same whether you have seen them before or not. CEF is commonly implemented in software using a multi-bit trie (mtrie) structure.
At any rate, the reason for blow based routing was back around 10+ years ago it was very difficult to do longest prefix match in hardware. One of the lesser understood consequences of CIDR is that it makes routing lookups computationally intensive, because you're not doing an "exact match" in your routing table you're looking for the "best fit" of the most specific route to a given destination. An early implementation shortcut was to use flow based routing as the fast path "cache" as described above, because it turned the routing lookup into an exact match problem (you find your exact flow that has already been programmed into hardware during the first slow path lookup), which was implementable at the time using cheap CAM (content addressable memory) from layer 2 switches.
The downside is that first slow path lookup, making it trivial to knock over routers with Denial of Service attacks, worms, or even just a generally bad traffic day. The solution was a hardware based CEF implementation, where the entire destination routing table is prepopulated into hardware, and longest prefix match lookups are done via ASICs. Today this happens in cheap devices because of TCAM (Ternary CAM) which lets you do wildcard matches, though many other technologies are beginning to pop up which are superior, such as Juniper's highly distributed lookups over cheap striped reduced latency DRAM (RLDRAM) in the MX platform.
The bottom line is there hasn't been a reason for flow based routing to exist in well over 7 years, and you won't find any modern implementations which even touch this. Today's routing lookup ASICs are incredibly cheap and efficient, and are among the least of the problems with implementing high speed routers at reasonable prices. Unfortunately this industry is full of aging quacks, and people who don't know enough to know better.
Ok, how do I buy stock in this company?
His current router handles 4million simultaneous flows. now considering a 'flow' is a connection between specific ports on specific machines, this reduced to well under 1 million when you start to introduce P2P traffic or multiple downloads or any other simultaneous traffic from end users which are popular these days. He is effectively replacing a generic lookup table with one that is 4 million entries long and calling it better. I don't really see the benefit.
Also, no matter what you do at the router, you have to have the bandwidth to support the traffic across your network, so this is a problem that you have to throw bandwidth at.
Uh. The article talks about Edge Routers and like someone already said, we have MPLS for this reason that they like to call "flow". Not only this, but WAN accelerators already optimize network operation by functioning at roughly 20 to 30 times the speed of networks without the accelerators.
I don't see how they are any different from any of the other companies like Cisco, Juniper, BlueCoat, or Riverbed.
The PC makers should just preload each computer with porn. Would save a lot of bandwidth :)
Ed
ArsTechnica had a great article about this a month ago: http://arstechnica.com/tech-policy/news/2009/07/mind-the-flows-and-the-packets-will-take-care-of-themselves.ars
Basically this is really nothing new technologically, and is more of a marketing ploy than anything else. The Ars piece is pretty well written and an interesting read.
I've met Larry Roberts in person a couple of times- once when he visited my lab, and once at a photonics meeting. He is the nicest / most humble person of his stature I've ever met (he was the director of the team that led Arpanet- the predecessor to the Internet). He spoke about flow routing about a decade ago and at the time he was CTO of a startup called Caspian - which I seem to recall ended up licensing the technology to NTT. But if you've ever heard Larry speak, he is truly brilliant and will go down to the nitty gritty details with you - which is rare for someone in his position.
The author's explanation around hashed forwarding is pretty uninformed. Between hardware based lookups and MPLS, we have all of the forwarding benefits in devices today to avoid queuing due to forwarding lookups. With an RSVP-TE signaled forwarding plane we even have a more granular control over MPLS forwarding to avoid the massive over-provisioning of bandwidth. If some of the Tier 1s haven't figured this out, let them keep spending too much money.
However, there IS something this box does which is unique. He describes it as giving a per-flow ability to DROP traffic. This is something most core-level routers can't handle today. If they are forwarding via MPLS in the core there will be no 5 tuple match to perform RED on. An NPU based box sitting in the core (his 80gbit scale needs to get bigger for that spot in the network) that can drop based on IP flow information has the potential to be powerful.
However, since the Internet providers are being forced towards a completely neutral dump pipe model, I don't know that they will be able to make the decision on which application or customer to drop in preference of another. Do we really want applications masking themselves as other applications to stay away from this intelligence? In the end, this type of intelligent dropping may be best served in the enterprise network or VPN provider network rather than the Internet.
This STILL isn't mainstream? What are these people, NASA?
At $70K, I'm not sure I'll be picking one of these up anytime soon. Don't love my porn _that_ much.
"2. The flow engine keeps track of each flow's duration and throughput to identify its type. It can selectively discard packets to protect Web, voice, and video while limiting peer-to-peer flows."
What if your voice app is running over a peer-to-peer system?
Let's take a look at this: This guy is decrying the state of routers with his doom and gloom setup, and then following up by saying that he can save everyone with this new router that he's selling. I dunno about you, but that sounds a little bit like marketing to me. What happens when these routers are bombarded by a great deal of small flows? Then as it tries to route them to their respective destinations, it becomes overloaded by the sheer number of flows that it needs to deal with.
This may be an improvement for Youtube style traffic, but not all traffic is like that. If this guy's claims are correct, then the best strategy would probably be to have a mix of these flow based routers and traditional routers, that way they can deal with either situation (many small flows or a few big ones).
Though I would take this guy with a grain of salt either way.
Uhm, yes.. the "Internet Inventor" is selling snake oil and he knows it. That's the real reason Caspian Networks failed and this new Anagran company is basically a non-entity in the routing market space.
Isn't this just a re-hashing of the difference between TCP and UDP? It almost seems like it will replicate UDP in hardware. For things like streaming media and VOIP you can loose a couple of packets here and there without noticing any loss of quality so things like that typically use UDP because it doesn't bother to go back and re-send those lost packets it just keeps going, while TCP will panic and wait untill it receives every bit of data. There is certainly a need for both TCP and UDP connections depending on what kind of data you are working with, so if it is in fact just recreating a UDP like connection how will it work when sending data that absolutly requires that every packet get to its destination.