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

> I thought the LEDBAT target delay was 25 ms, but I might have missed some update. In BitTorrent's uTP it's 100 ms right now.

The LEDBAT target delay was increased from 25 msec to 100 msec in version -02, to match the uTP implementation.

-----Original Message-----
From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of arvid@cs.umu.se
Sent: Thursday, July 28, 2011 10:35 PM
To: Sampo Syreeni
Cc: Janardhan Iyengar; ledbat@ietf.org; tsv-area IETF list
Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway

Quoting Sampo Syreeni <decoy@iki.fi>:

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

I thought the LEDBAT target delay was 25 ms, but I might have missed some
update. In BitTorrent's uTP it's 100 ms right now.

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

It's important to understand what "target delay" means. In LEDBAT, it refers to
the delay on top of the lowest ever seen one-way latency from the source to the
destination. It does not include any fixed latency (such as the fixed latency
you have in routers for handling packets in each hop nor the speed of light),
the variable in the one-way latency is essentially entirely the time a packet
spends sitting in buffers. LEDBAT does not care about which buffer or where the
buffer is (whether it's your router, your modem, your ISP's router or your
destination's ISPs router etc.).

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

That sounds like a correct statement.

> 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 no buffer along the path can fit the target-delay amount of bytes, LEDBAT
would essentially behave like TCP, and (essentially) be just as fair as TCP is.

> > 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).

Right. It just happens to be people's modems that are the bottlenecks
(unsurprisingly).

-- 
Arvid Norberg
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat