Re: Traffic shaping

William Christensen wrote:
> Now say that Peer2 simply has to much data to send over it's, alotted
> three channels, to Peer1. Peer 2, using the control channel, asks Peer
> 1 if it can borrow two of it's channel for awhile and Peer 1 would
> become a receiver of five data channels and a transmitter of only 1
> channel. Peer 1 either relinquishes or refuses.
> Is this along the lines of what you want to happen?

The problem is that you are implementing BEEP over TCP. Whatever your
BEEP maximum is is what your TCP maximum is, too, unless BEEP has built
in traffic metering (which would require more smarts on the other end,
too). TCP implementations will start up doubling the packet size until
it reaches a triple-duplicate-ack event, and then it will scale itself
back. Over the steady state, it will establish a stable equilibrium
speed for whatever your network is based on packet loss (NOT speed
settings, NOT bandwidth use).

What you want is to make TCP (and UDP since we have to respect all
packets, even though UDP has no flow control!) scale appropriately, and
this is done by metering at a lower level (NOT a higher level) of the
OSI model.

That is, if you detect on your router that your TCP traffic is exceeding
a threshold, you must drop the TCP packets and let TCP correct itself
(the same is true for UDP). This must happen below layer 4 (the TCP/UDP
layer in the OSI model), NOT above. Otherwise we would have to have a
TCP connection for a BEEP connection encapsulating a TCP and UDP
connection, which is likely unfeasible.

What Steven wants is that this drop limit is dynamic, based on traffic
metering. This would likely require a daemon of somekind which watches
interface transmission statistics, and then inserts packet drops as
needed to shape TCP/UDP traffic.
Received on Sun Jul 23 17:26:45 2006