[3382] in linux-net channel archive
Re: your mail
daemon@ATHENA.MIT.EDU (Alan Cox)
Fri Jun 21 15:43:47 1996
From: Alan Cox <alan@cymru.net>
To: olaf@bigred.inka.de (Olaf Titz)
Date: Fri, 21 Jun 1996 09:47:27 +0100 (BST)
Cc: submit-linux-dev-net@ratatosk.yggdrasil.com
In-Reply-To: <m0uWfaz-000IecC@bigred.inka.de> from "Olaf Titz" at Jun 20, 96 11:00:00 am
> What has this issue to do with TCP? In theory, all a bandwidth limiter
> needs is a slower driver. Devices like SLIP or PPP do the slowdown by
> themselves too :-)
No. Its not PPP that does the slowdown. Its the congestion and dropping
properties of the link as a whole.
> This could be implemented as follows: On the sending side, simply
> limit the outgoing packet rate. Delay sending of a packet (on the
Oh dear, the sending side is a remote machine.
> should be subject to the delay constraint described above. As long as
> the delay is in effect, the receiver should answer each incoming
> packet with an ICMP source quench.
Whoopee, thats just DOUBLED the number of packets in flight.
> Can anyone with TCP and/or Linux driver internals comment whether such
> a scheme is feasible, and whether TCP is suited to handle the
> situation wrt. acks etc. by itself, given a slow-down network layer?
It is counter intutitive in some ways but the way to slow a remote TCP down
is to properly model a slow link including discarding packets
Alan
