Re: Traffic shaping

Dylan Griffiths wrote:
> 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, ...
>
Thanks Dylan for the above tip.......I have always had problems with my
compositions.
> 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.

> 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).
>
Yep I agree with your equation. Could I take it that "n" and "m" could
stand for channels (aka ports)? If so then using BEEP seems to be the
only solution, in this conversation that fits, the problem.
> 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.
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.
>
>
> --
> "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 19:56:55 2006