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 - [email protected], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
