> 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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, July 28, 2011 10:35 PM To: Sampo Syreeni Cc: Janardhan Iyengar; [email protected]; tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway Quoting Sampo Syreeni <[email protected]>: > 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 [email protected] https://www.ietf.org/mailman/listinfo/ledbat
