[3360] in linux-net channel archive
Re: Traffic shaper
daemon@ATHENA.MIT.EDU (Mike Kilburn)
Thu Jun 20 07:57:38 1996
To: Alan Cox <alan@cymru.net>
cc: mike@lserv.conexio.co.za (Mike Kilburn), alan@lxorguk.ukuu.org.uk,
roque@di.fc.ul.pt, linux-net@vger.rutgers.edu
In-reply-to: Your message of "Thu, 20 Jun 1996 09:32:06 +0100."
<199606200832.JAA19103@snowcrash.cymru.net>
Date: Thu, 20 Jun 1996 10:40:56 +0200
From: Mike Kilburn <mike@lserv.conexio.co.za>
>
> 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.
I see. Well I would not drop any frames so I guess what I am talking about
is not a traffic shaper but a "slow link simulator". The amount of buffer
space required to hold the receive data could get quite large if you were
trying to take a T1 down to a 14400kbs but it is quantifiable. The data
source will slow down in time after it "figures out" there is a slow link
in the path.
