Slashdot Mirror
ARPANET Co-Founder Calls for Flow Management
An anonymous reader writes "Lawrence Roberts, co-founder of ARPANET and inventor of packet switching, today published an article in which he claims to solve the congestion control problem on the Internet. Roberts says, contrary to popular belief, the problem with congestion is the networks, not Transmission Control Protocol (TCP). Rather than overhaul TCP, he says, we need to deploy flow management, and selectively discard no more than one packet per TCP cycle. Flow management is the only alternative to peering into everyone's network, he says, and it's the only way to fairly distribute Internet capacity."
Larry Roberts was co-founder of the ARPAnet, but he did NOT invent packet switching. That invention goes to Donald Davies of the National Physical Laboratory in the UK. His work was well-credited by the ARPAnet designers.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Yes, your computer will resend it. But it does even more! TCP interprets dropped packets as congestion and will reduce its load on the network, generally by 50%. Dropping more than one packet per round trip just serves to confuse TCP a bit more but the net effect is the same: reduce the load by 50%.
I have been told that the ability to do this has been around since the 1970s. Don't all equipment makers have some version?
Overhead. Right now, routers just track individual packets: receive a packet, look up the next-hop IP in the forwarding table (which might have 250,000 entries), and send it on its merry way. To do anything based on flows, routers would have to keep track of all the active flows, which amounts to all open TCP connections going through that router. For an active router, there would be millions of active flows at any one time, so the overhead would be huge. This would be like a NAT or stateful firewall device that could do line-rate forwarding at gigabit, 10G, or 100G port speeds.
You also have problems tracking flows; routes change, so while a router may be tracking an active flow, the flow may choose another path. The router has no way of knowing this, so it has to keep track of the flow until it times out (and the timeout would have to be more than just a few seconds).
There are flow-based router architectures, but they are not generally used for ISP core/edge routers because there are too many ways they can break.
Comment removed based on user account deletion
That's an ad hominem, and an unnecessary one at that. A proposal to change something so important as TCP is bound to fail unless it has significant technical merit. To make things simple, let's just assume that the proposer openly admits they were motivated by self-interest to make the proposal. And the result is: nothing changes. Heck, Al Gore could make this proposal, and it wouldn't change the fact that proposals that are deeply technical will be evaluated on a technical basis.
Yes, TCP congestion control relies on everyone following the protocol. If you hack your TCP stack to send each packet twice, not cut down the congestion window, etc., you can get better performance. In practice, anyone doing this on a scale large enough to be noticed (think Apple) would get yelled at by the ISPs. Big players wouldn't do it because if the majority of users tried to cheat their performance would get worse.
IMHO hacks like this don't help enough to go through the trouble of installing, and if they do help, they likely need both endpoints to cooperate in which case you might as well use a custom UDP protocol.
Tsunami -- You can't bring a good wave down!
When using Linux as a router there are already several ways to per-flow fairness. The simplest and most obvious one is Stochastic Fair Queuing. The problem is that commercial routers can't do that in hardware.
Netflow/Jflow are for statistics, and on the larger routers, they are just sampled (not every packet/flow is monitored, just one out of every N packets). Originally netflow could be used as a packet switching method on Cisco, but it is just for statistics now.
Yes, your computer will resend it but due to the sliding window protocol http://en.wikipedia.org/wiki/Sliding_window it will also reduce the speed at which it is sending. By dropping a packet TCP will detect congestion and reduce the size of the window. For every dropped frame it will reduce the window by a factor of 2. Each time an entire window is sent without a drop, it increases the size of the window by one.
So it quickly drops down to below the available bandwidth then slowly grows the speed up to it.
This normally happens auto-magically between the two ends of a TCP connection to grow the connection to the capacity of the smallest link in the chain as a result of random drop or FIFO queues. By tracking each flow and their window management, the window size and thus speed of the flow can be controlled by any hop in the chain.
RED is tricky to set up, but neither Blue nor PI require much tuning, if any. (I'm running Blue on all of my 2.6 Linux routers, and RED on all the 2.4 ones.)
Yes, I have. On all of my hosts and routers. It's a big win for interactive connections, but doesn't matter that much for bulk throughput.
Unless you're running some fancy link technology, you don't get to tune your MTU. If, like most of us, you're running Ethernet and WiFi only, you're stuck with 1500 bytes.
As for window sizes, they're pretty much tuned automatically nowadays, at least if you're running a recent Linux or Windows Vista.
There is no flow routing in Anagran solution - it is just per (TCP) flow shaper/policer that you put at the ingres/egress of your network.
Anyway, in 99% of cases to achieve same thing you could use Linux with SFQ queueing.
This actually looks like a form of something a lot of Cisco equipment already does to prevent "synchronization."
Let's say you have 500 hosts sharing a "fat pipe." If During peak times, the combined throughput used by TCP applications cause all available bandwidth on the link to be consumed. The result is, at that instant that all available bandwith is consumed, packets get dropped suddenly and indiscriminately. This means that 500 hosts all lose a slew of packets.
Per TCP specifications, when packets aren't acknowledged, all 500 hosts back off for a moment, and then retransmit at approximately the same time, causing another sudden burst in bandwidth usage, and more dropped packets.
This problem compounds until all hosts are simply busting packets, dropping packets, backing off, and repeating. The solution to this was a technique called "RED (Random Early Detection).
What this does is essentially detect when bandwidth is almost completely utilized, and then starts selectively and "fairly" dropping packets from the TCP streams. This causes the hosts to gradually back off, until bandwidth consumption is back in check. The result is that the whole "synchronization" issue is avoided, and the link is better utilized, as throughput is constant and reliable.
There is a variation called WRED or "Weighted Random Early Detection", in which certain types of packets get cut before others. This would allow the router to avoid dropping VoIP traffic, while implementing RED on non-realtime streams instead.
You can read more about this technique here: http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcconavd.html
The mechanism used is MPLS, using RSVP TE.
Essentially, traffic is classified based on chosen parameters (protocol, port, etc) and placed into logical tunnels, and each can reach the same destination via a different path. Every so often (depending on administrator configuration, often 15 minutes), the router looks at utilisation of each tunnel on each interface, and can signal a different path for various tunnels in case of congestion.
With suitably fine grained tunnels and hysteresis configured, oscillations can be kept at bay.
For a large network with no defined central backbone, it can result in very even distribution of traffic, even when source and destination networks are the same.
Sparks:Gadget:Beer Maker