[3359] in linux-net channel archive
Re: Traffic shaper
daemon@ATHENA.MIT.EDU (Alan Cox)
Thu Jun 20 07:34:51 1996
From: Alan Cox <alan@cymru.net>
To: mike@lserv.conexio.co.za (Mike Kilburn)
Date: Thu, 20 Jun 1996 09:32:06 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, mike@lserv.conexio.co.za, roque@di.fc.ul.pt,
linux-net@vger.rutgers.edu
In-Reply-To: <96Jun20.013823edt.106822-7187+6296@vger.rutgers.edu> from "Mike Kilburn" at Jun 20, 96 00:58:24 am
> But thinking about it in a much simpler way, if a driver at the link level
> just delayed delevery of all received data for a particular subnet (With lots
> of buffer space) to the network layer and likewise on the send side "appeared"
> to be busy to the network layer, then the effect must be the same as a link
> which is clocked at a lower rate at the physical level. Am I missing something
> here?
Yes. TCP knows the difference between a link that is slow and one that is
overloaded. They are different things. A TCP encountering a slow but
reliable path will keep a lot more data "in flight". So if you put a 1
second sleep in your code path the tcp layer sends 1 seconds worth more
data.
When TCP sees lost frames it starts to back off to the point its not losing
frames (ie so that its not congesting the link).
What a traffic shaper is doing is dropping some frames. Its effectively
sampling the input queue at the point each notional packet would have
completed and the next one is ready to send.
Alan
