[3401] in linux-net channel archive
Re: your mail
daemon@ATHENA.MIT.EDU (Eric Schenk)
Sat Jun 22 12:41:03 1996
To: dennis@etinc.com (Dennis)
cc: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Fri, 21 Jun 1996 18:19:23 EDT."
<199606212219.SAA10163@etinc.com>
Date: Sat, 22 Jun 1996 12:17:12 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Dennis <dennis@etinc.com> writes:
>
>>> 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
>
>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.
There is a difference between a persistent 10% drop rate that
is independent the senders transmission speed, and dropping
packets due to congestion. TCP reacts to packets getting dropped
by shrinking its congestion window. This slows down its transmission rate.
If slowing down transmission results in no packet drops we win.
[This would be the case in the proposed traffic shaper.]
However, if slowing down transmission has no effect on the drop rate,
then we just keep getting slower and slower.
TCP just isn't designed to deal well with a "noisy" communications path.
[That said, TCP is prepared to deal with a single packet drop per
window without slowing down, so it will tollerate a slightly noisy
communications path. 10% drops is to high for this, if the packets
getting dropped are distributed uniformly you would expect back to back
drops to happen fairly often. This will hose TCP.]
There is probably an interesting research question buried in here.
Is it possible to have a TCP flow control algorithm that can tell
the difference between congestion and a flaky line?
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
