"Dr. Larry Roberts, co-founder of the ARPANET and inventor of packet
switching, predicts the Internet is headed for a major crisis in an article
published on the Internet Evolution web site today. Internet traffic is now
growing much more quickly than the rate at which router cost is decreasing,
Roberts says. At current growth levels, the cost of deploying Internet
capacity to handle new services like social networking, gaming, video, VOIP,
and digital entertainment will double every three years, he predicts, creating
an economic crisis. Of course, Roberts has an agenda. He's now CEO of Anagran
Inc., which makes a technology called flow-based routing that, Roberts claims,
will solve all of the world's routing problems in one go."
Anyone have any experience with these Anagran flow routers? Are they
that much of a departure from traditional routing that it makes a big
difference? I haven't done a lot of research into flow-based routing
at this point, but it sounds like this would be similar to the MPLS
approach, no?
How about cost per port versus traditional routers from Cisco or
Juniper? It seems that he cites cost as the main point of contention,
so are these Anagran routers truly less expensive?
I don't know, this is mildly offtopic (aka, not very operational) but the
article made me giggle a few times.
a) It resembles too much of Bob Metcalfe predicting the death of the
Internet. We all remember how that went (wasn't there NANOG tshirt with
Bob eating his hat?)
b) In the words of Randy Bush, "We tried this 10 years ago, and it didn't
work then". Everyone was doing flow-based routing back in '90-95 (cat6k
sup1, gsr e0, first riverstoned devices, foundry ironcore, etc). Then,
everyone figured out that it does not scale (tm Vijay Gill) and went to
tcam-based architectures (for hardware platforms) or cef-like based
architectures for software platforms. In either case, performance doesn't
depend on flows/second, but only packets/second.
Huge problem with flow-based routing is susceptibility to ddos (or
abnormal traffic patterns). It doesn't matter that your device can route
1mpps of "normal" traffic if it croaks under 10kpps of ddos (or
codered/nimda/etc).
-alex [not mlc anything]
[mlc]
When we start migrating to IPv6, wouldn't state-aware forwarding be
required for a good part of the traffic that is being translated from
customer IPv6 to a legacy IPv4 ?
I'm a personal fan of topology-based forwarding, but this is limited
to the address space of the topology we currently use, which is
running out of space in a few years (few meaning whatever version of
the IPv4 RIRs deadline you believe in).
Rubens
Anyone have any experience with these Anagran flow routers? Are they
that much of a departure from traditional routing that it makes a big
difference?
There's no difference in routing per se. Rather it's in-band
signaling of QoS parameters to provide feedback to queue management.
I haven't done a lot of research into flow-based routing
at this point, but it sounds like this would be similar to the MPLS
approach, no?
There is no setup phase. Signaling is in-band and periodic. The
theory is that every once in a while a control packets is sent, with
the same src/dst as the regular data packets. Whatever paths the
packets take, the control packets will take the same paths.
Paul Vixie wrote:
"Dr. Larry Roberts, co-founder of the ARPANET and inventor of packet
switching, predicts the Internet is headed for a major crisis in an article
published on the Internet Evolution web site today. Internet traffic is now
growing much more quickly than the rate at which router cost is decreasing,
Roberts says. At current growth levels, the cost of deploying Internet
capacity to handle new services like social networking, gaming, video, VOIP,
and digital entertainment will double every three years, he predicts, creating
an economic crisis. Of course, Roberts has an agenda. He's now CEO of Anagran
Inc., which makes a technology called flow-based routing that, Roberts claims,
will solve all of the world's routing problems in one go."
So I seem to recall flow cached l3 switches being rather common. 
Over here in the firewall business we offload flows from the firewall
policy enforcement engine into flow cached forwarding engines. In both
cases (switch/firewall) you trade one expense (fib lookups) with another
(keeping track of flow state for the purposes of forwarding). Since
statefull inspection firewalls have to track flow state anyway paying
the flow state tax is a built in assumption.
The problem of flow cached switches was the first packet hitting the
processor from each flow. Most of the flows are rather short so the
processor ended up with more than it's share of the heavy lifting for
the prevailing internet style traffic workloads. I suppose if one pushed
flow caches down into the forwarding engines of current router asics you
could reap the benefits of not performing a longest match match lookup
on every packet, though mostly you just have another look aside
interface and yet more memory contributing additional complexity that's
poorly utilized in worse case workloads...
Like I said if you're buying a firewall or a load balancer you probably
get to pay this tax anyway, but the core router customer voted with
their wallets a while ago, and while revisiting the issue occasionally
is probably worth it I wouldn't expect flow caching to be the revolution
that got everyone to swap out their gear.
I read over the vendor's site when that article was sent, and I'll be
honest, a lot of what they are trumpeting are steps backwards in
router performance.
While the site is pretty light on the details, Anagram's "Fast Flow
Routing Architecture" sounds very similar to dated multilayer switching
approaches. CEF-like adjacency certainly provides higher routing
throughput with less overhead. So if it's a win, it must be a win
because the cost of going back to a flow-caching is offset by a gain
in better QoS.
Their QoS details are a bit sketchy, but this would worry me:
BTC basically '"watches" every flow. By constantly comparing each
flow's behavior over time against a simple set of operator-defined
rules per flow class, BTC can identify "suspect" flows that by virtue
of their duration, byte count, source/destination, or other criteria,
require some form of corrective or policing action.
So now there's a "flow table" that in the forwarding plane. What
happens when the flow table overflows? How does the router decide
when to age-out a flow?
I have yet to see a flow-centric filtering device save the network
when it's flow/session table is what's under attack.