Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!GLACIER.STANFORD.EDU!jbn
From: jbn@GLACIER.STANFORD.EDU (John B. Nagle)
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  overly short RTT's
Message-ID: <8611121150.AA17991@ucbvax.Berkeley.EDU>
Date: Fri, 7-Nov-86 18:01:11 EST
Article-I.D.: ucbvax.8611121150.AA17991
Posted: Fri Nov  7 18:01:11 1986
Date-Received: Wed, 12-Nov-86 22:15:40 EST
References: <8611070406.AA28280@ucbvax.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: glacier!jbn (John B. Nagle)
Organization: Stanford University, IC Laboratory
Lines: 42
Approved: tcp-ip@sri-nic.arpa

> Should the gateway know them (transport protocols) all?

     I gave some serious thought to this approach back in 1984, and went
so far as to start writing a TCP segment consolidator for a gateway.
But the complexity of such a thing is comparable to the receive side
of a TCP implementation, and the possibility exists of introducing a class of
bug for which the assignment of blame would be very difficult.

     It was after discarding this line of attack that I came up with
"fair queuing", as described in RFC970.  The key idea there is that
gateways should have queuing strategies that favor well-behaved hosts
over badly-behaved ones, rather than the reverse, so that it is in the
self-interest of hosts to be well-behaved.  This was a radical idea when
I first proposed it, but gradually the community seems to be coming around
to the point of view that non-FIFO queuing strategies in gateways are
desirable.  

     Now that we know how to throttle TCP connections effectively over
a speed range of three or four orders of magnitude, and now that 4.3BSD
and some other implementations have the machinery to do this correctly, 
we should be able to make the whole Internet run smoothly over a wide
range of loading conditions.   With smarter algorithms in the gateway
to control the throttling and to prevent ill-behaved hosts from
using up most of the resources, it should be possible to stop the
present abysmal behavior of the Internet under heavy load.

     I hate to say "I told you so", but I did predict the congestion
collapse of the Internet in my article in ACM Computer Communications
Review in October 1983.  From the reports I read here, it has happened.
I've proposed ways to deal with the problem, and those that have been
tried have worked.  There's been some "not invented here" grousing,
but no one has shown that my approaches are invalid.  There may indeed
be more elegant solutions to some of these problems.  (Lixia Zhang
at MIT is working on some).  But unless someone has a better idea that
will stand scrutiny by the community, I suggest that somebody put
fair queuing in a few key gateways and see if things get better.

     The description of the algorithm in RFC970 is a bit sketchy, so if
you want to implement it and are a bit confused, please feel free to get
in touch with me and I will try to be of assistance.

				John Nagle