Re: Traffic shaping

Dylan Griffiths wrote:
> 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).
>
I don't understand what the BEEP maximum and TCP maximum is -- but BEEP
could use all 65,536 of the peers ports for it's 65,536 channels. The
original question from Steve is "traffic shaping solution which allows
you to pool
your available bandwidth for up or down use". The BEEP solution says
preallocate the number of available channels, aka ports, in half. Let
the other peer be a client on it's half and your peer be a client on the
other half. If one side has more clients that need servers, that is on
the other peer, then the two peers negotiate for temporary usage of
transmitting (aka client ports ) channels from the other peer. The
available bandwidth is now being used by the peer who needs the most
clients (aka client ports) channels. Each channel would have the
ability to hook one of it's client to one server on the on the other
peer. And all client/server interaction (aka data) would flow on that
one channel.

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.
UDP and TCP should work under BEEP.

>
> 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.
I don't understand how drop limits and inserting packet drops in having
pools of dynamic bandwidth?
>
>
> --
> "Well, there's SPAM, egg, sausage, and SPAM. That's not got MUCH SPAM
> in it."
>
> To unsubscribe, send a message with the word "unsubscribe" (without the
> quotes) in the body to linux-request@slg.org
> Archives are at http://list.slg.org/
>
Received on Sun Jul 23 18:42:25 2006