Re: Traffic shaping

William Christensen wrote:
>>> 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.
>
> I didn't write the above sentences.

No, but they are still correct. You throttle TCP and UDP by dropping
packets, not by limiting port use. Limiting port use does nothing to
affect the flow of traffic, it only artificially limits you to a
particular # of connections.

> Your right I dropped the word "AIDs" in my sentence. Could I not
> throttle TCP and UDP by allowing only so many ports to be used -- in the
> case I was citing, to throttle how many clients can use the bandwidth.
> If the problem can not be solved with the throttling of clients maybe
> the BEEP peers could negotiate by the amount of data each side wants to
> send at a particular time.
> Food for thought.

Here's some suggested reading:
http://www.freesoft.org/CIE/Course/Section4/4.htm
http://www.cs.unibo.it/~gabbri/LucArchInt/cap3b/img008.jpg

Packet ack rates are what cause TCP flow control to work, not port
numbers. Limits ports (as in your BEEP idea) will have no effect,
except additional complexity that must be managed on both ends.

if you look at
http://www.csm.ornl.gov/~dunigan/netperf/wadfaimd.gif

You'll see that the green line models a TCP connection that's being
throttled to roughly 1.5 Mbps. Once the outgoing speed reaches 1.5Mbps,
the router drops a packet. This leads to a triple-duplicate ACK
situation (how TCP detects packet loss), and a change in its window size
and data throughput.

Basically, you keep saying/asserting that BEEP (which uses a subset of
ports for a virtual-circuit setup) is the correct way of throttling
traffic, and I keep re-explaining how TCP's throughput control works --
and how it has NOTHING to do with ports.
Received on Sun Jul 23 20:17:35 2006