[3355] in linux-net channel archive
Re: Binary Driver Issues
daemon@ATHENA.MIT.EDU (Eric Schenk)
Thu Jun 20 05:12:42 1996
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
cc: mike@lserv.conexio.co.za (Mike Kilburn), roque@di.fc.ul.pt,
linux-net@vger.rutgers.edu
In-reply-to: Your message of "Wed, 19 Jun 1996 17:23:47 EDT."
<m0uWUj5-0005FaC@lightning.swansea.linux.org.uk>
Date: Thu, 20 Jun 1996 01:28:48 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> A traffic shaper - like delay the acks which will slow down the sender
>> for one thing. Slowing down the taking of data by the driver on the tx
>> side as well.
>
>"Delay the acks" - this is the nearest TCP equivalent to urban folklore I've
>met. You can delay the acks but until you delay them to the point of a zero
>window the sender just opens the congestion window up to allow for your delay
>thinking you are a very bad path.
Indeed. This myth seems to come out of the idea that the ACKs clock the rate
at which TCP sends new packets into the system. As Alan points out this
is not exactly true. Until the sender hits a zero window it is always trying
to increase its bandwidth usage. Initially this increase is exponential,
until a packet loss occurs, after which the increase is only linear.
If all you do is delay ACKs, and you do so in a smooth manner (say
adding the same delay to every ACK, or some sort of delay based on the
bandwidth you think you want to offer) then TCP will open the congestion
window exponentially until it its the zero window. After this you'll
get a series of zero window probes until the window opens up, and
then you'll get a storm of packets again, ad infinitum.
This is NOT the way to implement bandwidth limiting, it only slows down
the initial rate at which you get hit over the head by some constant factor.
If you really want to implement a throttle then you must either
throw away packets that arrive at your machine exceeding the bandwith
limits assigned to the source, or you must send ICMP source quench messages
down the pipe. The later, while attractive, is not a workable solution
because there are a fair number of TCP implementations that just ignore
source quench messages. Now, it MAY make sense to add some sort of ACK
delay into a throttle mechanism that throws away packets, but I wouldn't
place my bets either way right now.
[Aside: if you limit the TCP window to one packet, then the ACK rate
really does clock the rate at which packets get sent. However, this only
works if you get to pick the TCP window (forwarding systems won't get
this choice), and if you are willing to really throttle every connection
heavily. You can only send one packet per round trip delay with this method.
There is no middle ground.]
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
