[3363] in linux-net channel archive
Re: Traffic shaper
daemon@ATHENA.MIT.EDU (Alex.Bligh)
Thu Jun 20 14:23:08 1996
To: Mike Kilburn <mike@lserv.conexio.co.za>
cc: alan@lxorguk.ukuu.org.uk (Alan Cox), roque@di.fc.ul.pt,
linux-net@vger.rutgers.edu
In-reply-to: Your message of "Thu, 20 Jun 1996 00:58:24 +0200."
<96Jun20.013823edt.106822-7187+6296@vger.rutgers.edu>
Date: Thu, 20 Jun 1996 14:28:37 +0100
From: "Alex.Bligh" <amb@xara.net>
> >
> > "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.
>
> 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?
>
If you delay on a per packet basis, you will find the packets just get larger
as the TCP window increases in an attempt to get the same throughput on
a line with more delay. If you want to slow the datarate, the delay should
be proportionate to packet size (or better write a leaky bucket algorithm
based on bytes sent).
Alex Bligh
Xara Networks
