Re: Traffic shaping

Please read this page:
http://www.stormloader.com/garyes/its/#top

When I read, I automatically expand contractions. Your confusion about
contractions and possesives makes it very annoying to read your letters.

Anyway, ...

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.

Which is exactly why BEEP is not the solution for Steven. He wants the
lower level to automatically scale back traffic, not a higher level. He
wants to shape packet-switched streams. BEEP is a virtual-circuit
technology, orthogonal to the problem we have -- shaping multiple,
dynamic packet streams which have different flow control methods such
that the cap is always 2mb. BEEP is good if you have a fixed number of
channels between hosts, and you want reverse channels to become forward
channels if you have a higher rate of forward traffic (and vice-versa).
  You could run TCP and UDP over BEEP, but that is the wrong approach to
this problem as I've stated before. Let me explain.

Basically, he wants up + down to be capped at 2mb.
That is, 2mb = n * Up + m * Down (mm, that's much like the linear form
of the GCD found via Euclid's algorithm, except that n & m aren't
integers -- they're natural #s, since you can't have negative bandwidth).

You'd need some daemon to automatically rate-limit and adjust these;
this would be a userland policy program, since the kernel is limited to
mechanism -- not policy (at least in sane operating systems). What he's
asking for may or may not exist, but I doubt it exists since most people
are on asymmetrical connections and use something like Wondershaper
(which sets up a set of static rate limits based on traffic
classifications, instead of implementing a rate-setting policy daemon).

What I'd like to hear is what motivates this problem, because there
might be another solution that's simpler which we could suggest, but he
himself doesn't see.

>> 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?
>

I'm not sure what you mean by this sentence because you appear to have
dropped a word. If you mean "I don't understand how drop limits and
inserting packet drops *AIDs* in having dynamic pools of bandwidth,"
it's because that's how you throttle TCP and UDP (UDP is either
idempotent packets or has a mechanism to handle retransmission
implemented on top, and TCP is designed under the assumption that packet
loss = scaling back). If the word you dropped from this sentence is not
aids, I don't know what you mean.
Received on Sun Jul 23 19:12:07 2006