Anagran Promises TLC for TCP

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 2 / 2

zwixard 12/5/2012 | 3:04:23 PM

re: Anagran Promises TLC for TCP This described ISP Human Nature very well:
"
The point is that ISP's will always find it easer and cheaper and less hassle just to throw bandwidth at the problem
"
They want a sure way to deal with the capacity/QoS problem. Throwing money at proven technology will make the problem go away.

Reply | Post Message | MESSAGES LIST | START A BOARD

ozip 12/5/2012 | 3:04:22 PM

re: Anagran Promises TLC for TCP Zippy,

Flows and route caching are not really related. Its true that search-tree systems are better than caches however its a juggling act managing the tree size.

Flow based forwarding is more about how traffic moves through the box. For example, the Avici box, because of its fabric type carried all traffic in flows so it could take advantage of the multiple fabric paths between interfaces.

OZIP

Reply | Post Message | MESSAGES LIST | START A BOARD

mr zippy 12/5/2012 | 3:04:20 PM

re: Anagran Promises TLC for TCP Flows and route caching are not really related. Its true that search-tree systems are better than caches however its a juggling act managing the tree size.

Agree. I was using the route cache situation as an example of how having network devices create and maintain state based on a myriad of destinations isn't scalable. Route caching is a lesser example, as a single prefix will usually represent a range of destination IP addresses. The search-tree's size is dictated by the number of routes in the RIB, not the characteristics of the traffic is going through the router.

Basically I think the issue here is whether operating state in the router is data driven or control driven. If it is data driven, then there is the opportunity for a malicious user to create traffic patterns that can cause all the routers resources to be exhausted, whether that is CPU or memory or both. Alternatively, if the limits are reached, then the router could have an "all the rest" class, however that then is also preventing the router being effective at what it was fundamentally purchased to do. I'm interested to know if Anagran have solved this problem and if so, how?

Reply | Post Message | MESSAGES LIST | START A BOARD

StartupGrunt 12/5/2012 | 3:04:12 PM

re: Anagran Promises TLC for TCP I sure would be. It sounds to me that Roberts is leveraging all the research from Casipan into this new venture -- I wouldn't be surprised if the same source code shows up at some point.

As for the technology, I am really dubious that it can even be solved at the network services layer. For example if I were selling Video-on-Demand services as an ISP I would want the bandwidth-to-the-consumer guaranteed at the application layer at the time of flow setup, not just throw it out there and hope the routers are smart enough to let the packets through somehow. That is all best handled at the application level.

On the other hand if I had the ability to pull infinite money out of clueless but pliable VCs the way Roberts does, I wouldn't mind seeing if I could solve it.

Reply | Post Message | MESSAGES LIST | START A BOARD

zbalint 12/5/2012 | 3:04:11 PM

re: Anagran Promises TLC for TCP After reading twice the 'Inside the box' section of this article, I am still scratching my head for what good this box does.

First, who said that network load is 30% because of the influence of a single node along the micro-flow paths?

Second, suppose the only bottleneck is the edge router (the recommended position of the Anagran box), who said it can only take 30% traffic on a congested egress interface? If memory is 'cheap as mud', then all you have to do is add the right amount of buffers (see the work of Appenzeller, Gorinsky, and many many others); not to speak about RED and other TCP-friendly ways (RFC2859) to control traffic aggregates. And if all theory breaks down in practice, who said that modern gigabit networks need to work at 100% load for internet traffic? If I was a network engineer at an ISP, I would not aim to configure buffers for optimal TCP throughput, as that is already at too large delays (see Gorinsky: Link buffer sizing, or others).

Third, and most important, who will configure the policies for all those flows? An arbitrary TCP connection does not have an SLA. Service access points do, but those are not flows based but physical (DSL, WiMax, Fiber) or logical (eg: PPP session, PVC) interfaces. Each of those can carry an arbitrary number of flows, that all look the same deeper in the network.

Fourth, video and voice flows are not to be rate limited by policing and shaping. What good will that do? Connection admission control is to be performed at session establishment, and if that is successful, then prioritized over non-premium traffic all over the QoS-aware network. No need to grossly overprovision, and also no need to overcomplicate.

Perhaps there are valid issues that the Anagran box addresses, but I failed to understand that from this article. I'm curious what Sally Floyd or RFC2581 editors would have to say.

Quite frankly, it seems that this is yet another product where the biggest added value is in the marketing. But hey, since when is that reason for failure?

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 2 / 2