Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?

[Fred Baker <fred@cisco.com>]

On Mar 16, 2011, at 3:22 PM, Richard Scheffenegger wrote:

> Heretical question: Why must the congestion notification implemented as a (distributed) function of the network itself, and take the reaction of the end hosts into consideration. If the signaling would only indicate the local congestion state, but then move the reaction to that into the end hosts, i think the design would be much more simple.
> 
> If the network would let the (reactive) senders know the extent of the current congestion, the end hosts can use more smarts and react to it properly.

That's not heretical at all. You might be interested to look at Dina Katabi's XCP and Nandita Dukipati's RCP. Both work from the assumption that if a smallish information element is added to the network layer header by the transport and updated by routers en route, the end systems can calculate the correct window value and simply set it. Work on these protocols was done at MIT, USC/ISI, and Stanford over the past decade.

The problem is that it might have worked reasonably well in the 1990 Internet (although the "everything runs on IP" model didn't quite work there either), but doesn't reflect today's network. Think about various forms of tunnels (IP/IP, GRE, L2TP, ...), encrypted tunnel-mode VPNs such as the one I use every day to go to work, MPLS LSPs, Ethernet switches and especially Metropolitan Ethernet, and the today's broadband networks. In terms of modeling the network, the "Network of Networks" model is actually a pretty good one: IP tells the network *what* needs to be done, but the network then uses a vast array of underlying technologies to accomplish it. So saying "no problem, let the network update the IP header..." - the places that need to do so often can't see or can't change the IP header.

I'm very much in favor of ECN, which in all of the tests I have done has proven very effective at limiting queues to the knee. I'm also in favor of delay-based TCPs like CalTech FAST and the Hamilton and CAIA models; FAST tunes to having a small amount of data continuously in queue at the bottleneck, and Hamilton/CAIA tunes to a small bottleneck. The problem tends to be that the "TCP Mafia" - poorly named, but a smallish set of people who actually control widely-used TCP implementations - tend to very much believe in the loss-based model, in part because of poor performance from past delay-based implementations like Vegas and in part due to IPR concerns. Also, commercial interests like Google are pushing very hard for fast delivery of content, which is what is behind Linux' recent change to set the initial window segments. 

There is also a needed educational effort. My company is unlikely to turn AQM or ECN on by default because we don't have customers asking us to do so, and my company's customers tend to think that loss is an indication of errors in the network.