[3408] in linux-net channel archive
Re: shaper or whatever
daemon@ATHENA.MIT.EDU (Eric Schenk)
Sat Jun 22 15:59:40 1996
To: dennis@etinc.com (Dennis)
cc: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Sat, 22 Jun 1996 12:45:36 EDT."
<199606221645.MAA12747@etinc.com>
Date: Sat, 22 Jun 1996 14:42:37 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Dennis <dennis@etinc.com> writes:
>>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.
I suspect we are talking at slight cross purpose here.
As you say, delaying packets is not the same as throwing them away.
I don't advocate a traffic shaper that delays traffic or has any knowledge
of the TCP internals. I don't beleive such a strategy will work.
The traffic shaper would have to drop any packet that crosses the
box that exceeds the bandwidth assigned to the connection.
The contents of the packet (ACK, data whatever) are irrelevant to
the decision to drop. The only knowledge the shaper needs how to
determine if the packet exceeds the bandwidth assigned to the connection.
The connection a packet belongs to would have to be determined from
the addresses in the headers. Note that this approach should work
with a router just as well as a box that is acting as an end point.
There is some information overhead that would not be present on a
standard router. You need to track every active pair of end points
that are sending packets through your router. This need not look
to deeply into the protocol struture, a simple timeout to remove
the endpoints from the data structure should suffice.
>linux box as a router. An ISP, for example, has an undeterminable number
>of simulatanous connections, so "drops" become somewhat random.
I'm not quite sure what you are getting at here. If you mean that
on a large router who gets a packet dropped is somehwat random, then
this is of course true. I don't see how it is relevant to the issue at hand.
As an aside, a machine that is acting as a router may have better
aggregate behavior if it randomly chooses packets to drop from the queue
when needs to make room for incoming data. [As opposed to simply
dropping the incoming data.]
There is some pretty serious research into using these type of gateways
to smooth the congestion behavior of TCP networking.
>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.
Sure. But combined congestion window should not be confused with the
maximum window available on the combined TCP's open across a link.
In the long run the combined congestion windows should reflect the
real bandwidth of the link. In reality TCP is good at reacting to
increased congestion, but not very good at quickly taking advantage
of extra bandwidth, so the combined congestion windows could often
be smaller than the real avialable 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.
As noted above a router would need to track the bandwidth usage for each
pair of endpoints that is currently transmitting. This would needs a small
structure for each pair of end points. Say 12 bytes to specify the
endpoints, and say another 8 to specify the bandwidth limit and the
current traffic load on the connection. (I'm not sure what
the "best" way to characterize load would be. I suspect some sort of
smoothed exponentially decaying averager would be best, but I haven't
given this any deep thought.)
Add in a bit more overhead for a fast lookup data structure (say patricia
trees or some such thing) and we should still be within feasible memory
usage even for thousands of simultaneous active connections.
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
