[3430] in linux-net channel archive
No subject found in mail header
daemon@ATHENA.MIT.EDU (Olaf Titz)
Sun Jun 23 16:12:35 1996
Date: Sun, 23 Jun 96 13:21 +0200
From: olaf@bigred.inka.de (Olaf Titz)
To: submit-linux-dev-net@ratatosk.yggdrasil.com
Newsgroups: linux.dev.net
Path: not-for-mail
From: Olaf Titz <olaf@bigred.inka.de>
Subject: Re: your mail
Message-ID: <dtga8d.15r@bigred.inka.de>
Date: 23 Jun 1996 13:21:46 +0200
References: <m0uWfaz-000IecC@bigred.inka.de>
<199606210847.JAA17404@snowcrash.cymru.net>
Organization: private Linux site, southern Germany
Lines: 61
Alan Cox <alan@cymru.net> wrote:
> > 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.
Misunderstood. What I really meant was: the PPP device is slow because
it is not able to push data down the link faster than the device
speed. Perhaps this is too obvious but I imagine this could be used as
a model for a slowdown driver on faster networks.
What does happen when you stuff an ethernet with packets that are
routed to a PPP link? Somewhere in the abstract device layer there has
to be a send queue, and if that fills up because a 14.4kbps outgoing
isn't able to keep up with 10Mbps incoming, it has to discard some
packets, right?
> > 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.
No, I meant the sending side of the (local) net device. My intention
is to limit the packet rate that goes out from (say) eth1:1 as well as
what comes in from eth1:1 by pretending eth1:1 is a slow device.
Somehow it has to be possible to model the bandwidth situation of
10Mbps 14.4kbps
--------- router ------------
eth0 ppp0
in software so that it behaves the same on
10Mbps 14.4kbps limited
--------- router ------------
eth0 eth1:1
By "the sending and receiving side" above I referred to the sending
and receiving side of eth1:1.
> > 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.
Or send a source quench every second, or is there an RFC about when
and which frequency to send source quenchs? The link affected by the
ICMPs is not the timing critical one.
> 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
Exactly what I was trying to describe...
olaf
--
___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
__ o <URL:http://www.inka.de/~bigred/> <IRC:praetorius>
__/<_ >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____
