Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway

[Sampo Syreeni <[e-mail]>]

On 2011-07-28, Bob Briscoe wrote:

> I said in a residential network, LEDBAT won't yield to traffic sharing 
> any queue upstream of your own home gateway queue.
>
> LEDBAT's target delay is 150ms.

Target delay, but also a one designed to mimic the minimum delay over 
the whole path? No? A users's upstream cable modem being the most 
typical and biggest part of that, but still, isn't the protocol about 
the whole?

Shouldn't it then in theory be that LEDBAT quenches towards the minimum 
total delay, regardless of where the bottleneck might be? Any higher up, 
faster, less congested buffers ought to be totally neglected in the 
process because the lower, more filled up dominate the e2e delay 
calculation?

If not, then the quenching ought to happen because of the more congested 
link/filled up buffer, that is *now* causing the extra delay beoynd the 
minimum sensed.

> The root cause is the fixed 150ms target delay.

So what I (we?) am missing is that with very fast networks the protocol 
should be able to asymptotically go to zero latency, while staying nice 
and crowd-stable? Are there other, statistical considerations beyond 
this?

> If LEDBAT yielded to others, users would reject it.

They absolutely would not. In fact, they don't: it's in current use and 
is rapidly being adopted by the numbers, as uTP, within uTorrent (and 
others).

> We could design a LEDBAT-like protocol that yields to others in any 
> queue. But no-one would want it (yet). Incidentally, a goal of ConEx 
> is to incentivise deployment of LEDBAT-like protocols. The suffix 
> '-like' means that they would benefit from yielding to anyone, not 
> just your family in your home.

Yes. So I at least am missing something. I'm sorry to ask for looking a 
bit stupid, but... What *am* I missing, really?
-- 
Sampo Syreeni, aka decoy - [e-mail], http://decoy.iki.fi/front
[phone], 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2