[3403] in linux-net channel archive
RE: shaper or whatever
daemon@ATHENA.MIT.EDU (Dennis)
Sat Jun 22 12:58:58 1996
Date: Sat, 22 Jun 1996 12:45:36 -0400
To: "Eric Schenk" <schenk@cs.toronto.edu>
From: dennis@etinc.com (Dennis)
Cc: linux-net@vger.rutgers.edu
Eric Schenk writes...
>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.]
It the drops are truly persistant, then it is not much different, as TCP
reacts much the same. A packet that takes a long time to arrive and
a packet that never arrives are quite different.
>
>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?
This if fine if you limit yourself to small environments and dont use the
linux box as a router. An ISP, for example, has an undeterminable number
of simulatanous connections, so "drops" become somewhat random.
It also depends on how you define congestion. An ethernet connection that
is limited to 56k could be in a constant state of congestion, which complicates
your potential algorithm...particularly when with, say, 100 active
connections you
could have a window availability many times the available bandwidth.
You also can't control anything at the TCP level for traffic passing THROUGH
the box (rather than originating in the box). A router cant withhold or
delay an
ack, unless you plan on having the router learn about every connection that
passes through it.
Dennis
----------------------------------------------------------------------------
Emerging Technologies, Inc. http://www.etinc.com
Synchronous Communications Cards and Routers For
Discriminating Tastes. 56k to T1 and beyond. Frame
Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD
and LINUX
