[3419] in linux-net channel archive
Re: your mail
daemon@ATHENA.MIT.EDU (Alan Cox)
Sun Jun 23 10:31:43 1996
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
To: dennis@etinc.com (Dennis)
Date: Sat, 22 Jun 1996 15:10:16 +0100 (BST)
Cc: alan@cymru.net, linux-net@vger.rutgers.edu
In-Reply-To: <199606212219.SAA10163@etinc.com> from "Dennis" at Jun 21, 96 06:19:23 pm
> >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
> If you discard packets then you are not modelling a slow(er) link.
> Packets that are discarded change the characteristics of the connection
> for those packets with a result that is not acceptable to end user
> applications. Anyone whose been on a flakey link knows that a T1 line
> that drops 10% of its traffic yields unacceptable throughput due to the
> timeouts, certainly no-where near 90% of T1. More like 8k.
Wrong...
The properties of modelling a slower link are precisely those of dropping frames
once you pass the point at which the real link would drop packets. By dropping
packets you cause the TCP layer to do congestion control and lower its end to
end send rate. Thus you don't end up dropping 10% of traffic, you drop a few
packets occasionally and the other end figures out the real throughput and
adjusts. The end result is almost no packets lost.
The TCP layer with traditional flow control sets out to find
1. How many packets can be "in flight". This measures the available buffers
that can be committed along the link without loss.
2. The round trip time of the link. This allows the TCP to tell when to
retransmit a frame.
The flow is regulated solely by #1 above assuming the windows are large enough.
A slow hop on a link causes less buffers to be "in flight" at once without loss
as it will buffer only a small number of frames (smoothing noise in the traffic
flow).
Alan
