[3368] in linux-net channel archive
Re: Binary Driver Issues
daemon@ATHENA.MIT.EDU (Dennis)
Thu Jun 20 16:49:48 1996
Date: Thu, 20 Jun 1996 11:21:33 -0400
To: "Eric Schenk" <schenk@cs.toronto.edu>
From: dennis@etinc.com (Dennis)
Cc: linux-net@vger.rutgers.edu
Eric Schenk writes.....
>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.
You can implement a very crude bandwidth limiter by managing acks, but you
cannot do it precisely (a criteria if you are paying for bandwidth) and the time
that it takes to reach an equilibrium is unpredicatable and unacceptably long.
The bottom line is that there is no reason to muck with the TCP...its too
dangerous in terms of keeping your system stable.
Receive bandwidth limiting is perhaps not possible, at least if your goal is to
achieve simulation of lower physical bandwidth. To get bidirectional limiting we
require 2 interfaces through a box. For WEB for FTP hosting you only really
need to control the transmit on one interface, as traffic is largely
monodirectional
out of the box.
Dennis
----------------------------------------------------------------------------
Emerging Technologies, Inc. http://www.etinc.com
Synchronous Communications Cards and Routers For
Discriminating Tastes. 56k to T1 and beyond. Frame
Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD
and LINUX
