This is more like an ad than an article. Flow-based routers have been developed in the past, and the reason they are not prevalent is due to performance issues of one kind or another.
If they truly have solved the problem(s) that other flow-based routers had, great, but this can only be determined in the real world.
I think it's faster for flow control and packet filtering, not just faster in general.
The illustration states that P2P traffic is problem to be solved by this router. Article also states:
"How Flow Routing Works
Flow managers keep track of streams of packets and can protect voice and video transmissions while reducing peer-to-peer traffic."
"Worse, peer-to-peer (P2P) services, used to download movies and other large files, are eating more and more bandwidth. P2P participants may constitute only 5 percent of the users in some networks, while consuming 75 percent of the bandwidth."
Also seems like this would make tiered internet easier in general. Doesn't this router have big implications on the Net Neutrality debate?
Tiered access requires particular connections to be statically limited. That is already easy to do. This device applies limits dynamically based on throughput and duration, which seems pretty fair and neutral to me.
What I don't understand is how it distinguishes between audio/video streams and P2P traffic. I would think them pretty similar without inspecting packets.
The way I read it, it can also contribute to improving neutrality: you can now try to commission the same amount of bandwidth to each user. Whereas with individual package-handling a user could impact other users by sending lots of packages, now these would be treated as a group belonging to one ID. It's also less murky then deep packet-inspection...
It would have been appreciated if the author could have compared his technology against CEF+CBQ. Suggesting that routers process switch each packet and don't treat different classes of traffic differently when avoiding congestion with packet drops is like suggesting we divide IP spaces using classful addressing. True in 1993, but...
It annoys me when router vendors (Cisco, looking at you) advertise their throughput as theoretical maximum bi-directional. Almost no real network design can take advantage of that speed. If this router only has 4x10g port (the two left cards), for all intents and purposes it's a 40-50gbit router. That's probably a great deal in the $50-100k range, though, so there's still a place for it.
I feel like I'm telling Larry Wall what is up with Perl or something, but this guy is making route caching sound like something new, when it has been in crappy $4000 workgroup-class layer three switches now for almost a decade. This kind of deflates his "I should know" appeals to authority.
The buffer-alternative algorithm isn't well explained but sounds kind of novel and useful. It would be particularly so if it allows the network operator to manage flows on a per subscriber basis.
One other concern: if this router is cutting power/weight corners by decreasing its ability to calculate new routes ("flows"), it's possible that an ISP would be exposing themselves to a DoS of their network by intruders sending a lot of unique flow requests to the router. An obvious example of this would be several concurrent NMAPs of a large range of IPs.
If it can keep up with the large workloads they claim with only 300w and 3U (or so) of space, it's pretty compelling, all of these issues aside. I'm excited to see it in the real world.
My take is that flow routing is not necessarily cheaper than doing full routing on every packet, but building a router with virtually no buffers requires tracking flows and interacting with TCP.
I suppose the DoS you mentioned should be relatively easy to prevent. They don't have to cache all flows, just the most hot 20% which consume 80% of bandwidth. Probabilistic caching and/or ruthless pruning of cold flows can probably render the "exploding cache" attack impossible or at least impractical.
What bothers me more is routing table updates. I don't see how they can avoid invalidating the whole flow cache on each routing flap. OTOH, rebuilding the said top 20% of flows should be pretty fast, too.
I see no mention of UDP in this article, which is what 99% (if not more) voice and video traffic is transmitted as (omitting stuff wrapped in HTTP). Can it also detect flows of UDP?
TCP and UDP packets look pretty much the same as far as this design is concerned. It's all IPv4 where the IP header has IP source/dest address and a TCP/UDP bit. The source/dest _ports_ are in the first 32 bits of the TCP or UDP portion of the message. So it should be trivial to include UDP, but that probably wasn't mentioned because it would be "too technical" for this level of ad.
Is computing a hash over 4x4bytes (+1 protocol bit) really faster than looking up an address (that is only 4bytes long, btw) in an optimized routing table ?
Yes, because every address seen by the router isn't in some simple lookup table in the router, unlike the flow table (or the CEF table or whatever your hardware has).
That's not to say this is a huge win --- I don't think it is --- but yes, flow lookups are a simpler problem than per-packet routing and per-packet N-dimensional classification.
If they truly have solved the problem(s) that other flow-based routers had, great, but this can only be determined in the real world.