[Iccrg] Heresy following "TCP: Train-wreck"
mathis at psc.edu
Wed Apr 2 17:35:11 BST 2008
I just attended the "The Future of TCP: Train-wreck or Evolution?" at Stanford
last week, and it solidified my thoughts on a subject that is sure to be
I think it is time to abandon the concept of "TCP-Friendly" and instead expect
the network to protect itself and other users from aggressive protocols and
applications. For the moment I am going to assume two mechanisms, although I
suspect that there will prove to be more.
1) Deploy some form of Fair Queuing at the edges of the network.
2) Protect the core by bottlenecks at the edges of the Internet.
I observe that both of these mechanisms are already being implemented due to
existing market forces, and the natural consequence of their implementation is
to make TCP-friendliness a whole lot less important. I admit that it is not
clear at this point if these two mechanisms will ultimately prove to be
sufficient to address fairness all situations, such as over loaded core
routers, but I suspect that sufficient mechanisms do exist.
FQ is already being deployed at the edges to solve several existing and
growing fairness problems:
* Non-IETF, UDP protocols that are non-responsive.
* P2P and other applications that open huge numbers of connections.
* Stock TCP is egregiously unfair when very short RTT flows compete with wide
area flows. This can be a real killer in a number of settings such as data
centers and university campuses. The symptoms of this problem will become
more pronounced as TCP autotuning continues to be rolled out in Vista,
Linux, and various BSDs.
* Autotuning will also greatly magnify RFC 2309  problems, since every
single TCP flow with sufficient data will cause congestion somewhere in the
network. At the very least this will gradually force the retirement of
drop-tail equipment, creating the opportunity for RED and/or FQ. Since RED
by itself is insufficient to solve the other fairness problems, it will not
be the first choice replacement.
I should note that "Fair Queuing"is overly specific. The network needs to do
something to large flows to prevent them from overwhelming smaller flows and
to limit queue occupancy. FQ is one way, but there are others.
If you have ever shared a drop-tail home router with a teenager, you might
have observed some of these issues first hand, as has Comcast. As I
understand it, some form of enforced fairness is now part of all commercial
The core of the Internet is already mostly protected by bottlenecks at the
edges. This is because ISPs can balance the allocation of revenue from
customers between the relatively expensive access link, its own backbone links
and interconnections to other ISPs. Since congestion in the core has proven
to cause complaints from commercial customers (and perhaps SLA problems), most
providers are careful to keep adequate capacity in the core, and can do so
pretty easily, as long as their duty cycle models hold true.
Are these two mechanisms sufficient to make TCP-friendliness completely moot?
We still have some work to do:
First, stop whining about non-TCP-friendly protocols. The are here to stay
and they can't hear us. We are wasting our breath and impeding real progress
in well designed alternatives to "TCP-friendly". This concept came from an
era when the Internet was a gentleman's club, but now it needs to be retired.
Second, blame the network when the network deserves it. In particular if
there are drop tail queues without AQM, be very suspicious of RFC2309
problems. In fact every drop tail queue without AQM should be viewed as a bug
waiting to bite someone. Likewise remember that "TCP-friendly" is extremely
unfair when the RTTs are extremely different.
Third, think about the hard cases: over loaded interconnects, failure
conditions, etc. Can FQ be approximated at core scales? Where else are my
proposed mechanisms insufficient? I sure there are some.
Fourth, start dreaming about what it would take to make Moore's law apply to
end-to-end protocol performance, as it does to just about everything else in
the computing universe. I suspect that in some future hindsight, we will come
to realize that TCP-friendly was actually a untenable position, and has held
us back from important innovations.
 RFC2309 "Recommendations on Queue Management and Congestion Avoidance in
the Internet", Bob Braden, et al.
 Richard Bennett "New and Improved Traffic Shaping"
It was a very stimulating conference!
Thanks Nandita and everyone else who made it happen!
Matt Mathis http://staff.psc.edu/mathis
More information about the Iccrg