Subject: LEDBAT doesn't help sharing network beyond home gateway

From: Bob Briscoe <[email-masked]>
Date: Thu, 28 Jul 2011 11:23:44 -0400

Jana,

You asked the basis of what I just said in TSVAREA. 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.

A typical shared link in such a network will be 1Gb/s.

150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if 
1500B per pkt).

The buffer will not be this big (unless there's more bloat than 
anyone would expect)! Therefore LEDBAT will drive the queue off the 
end of its tail, just like TCP does. Therefore LEDAT is not designed 
to yield to others in such a queue into a higher speed link.

The root cause is the fixed 150ms target delay.

Nonetheless, I believe this design choice makes sense for LEDBAT 
_today_: you only yield to others in your own home. You don't yield 
to others in other homes.

If LEDBAT yielded to others, users would reject it. Evidence is on 
the Bittorrent community postings when uTP was 'imposed' on 
BitTorrent users - it was only accepted because it was shown that 
performance didn't suffer unless it was yielding to self.

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.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Rolf Winter <[email-masked]>
Date: Thu, 28 Jul 2011 23:29:29 +0000

One clarification. The target is 100ms, can be less, but not more. The "can be less" part is to cater for the future. The cannot be more is to make sure you cannot be unfair unless you chose to be non-standards compliant.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bob Briscoe
> Sent: Donnerstag, 28. Juli 2011 17:24
> To: Janardhan Iyengar
> Cc: [email-masked]; tsv-area IETF list
> Subject: [ledbat] LEDBAT doesn't help sharing network beyond home
> gateway
> 
> Jana,
> 
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 28 Jul 2011 23:59:26 +0000

Bob, agree & great point. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: Thursday, July 28, 2011 8:24 AM
To: Janardhan Iyengar
Cc: [email-masked]; tsv-area IETF list
Subject: LEDBAT doesn't help sharing network beyond home gateway

Jana,

You asked the basis of what I just said in TSVAREA. I said in a residential network, LEDBAT won't yield to traffic sharing any queue upstream of your own home gateway queue.

150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if 1500B per pkt).

The buffer will not be this big (unless there's more bloat than anyone would expect)! Therefore LEDBAT will drive the queue off the end of its tail, just like TCP does. Therefore LEDAT is not designed to yield to others in such a queue into a higher speed link.

Nonetheless, I believe this design choice makes sense for LEDBAT
_today_: you only yield to others in your own home. You don't yield to others in other homes.

If LEDBAT yielded to others, users would reject it. Evidence is on the Bittorrent community postings when uTP was 'imposed' on BitTorrent users - it was only accepted because it was shown that performance didn't suffer unless it was yielding to self.

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.

Bob

---

From: [email-masked]
Date: Fri, 29 Jul 2011 04:34:40 +0200

Quoting Sampo Syreeni <[email-masked]>:

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

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

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 29 Jul 2011 04:19:57 +0300 (EEST)

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Jul 2011 07:49:49 +0200 (CEST)

> LEDBAT's target delay is 150ms.

What about loss? If there is a RED profile that starts dropping at 30ms 
and has 100% drop at 100ms, would LEDBAT behave mostly like TCP?

I agree with other posters in this thread that at 100ms, LEDBAT will only 
lessen congestion on hour own link, because most of the time a provider 
core will never buffer 100ms, it just doesn't make sense.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 29 Jul 2011 03:57:02 +0000

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