Re: [ledbat] [R-C] LEDBAT vs RTCWeb

[Rolf Winter <[e-mail]>]

> > the way I remember how we got to the 100ms was a little different. We
> started out with 25 ms of extra delay and between version 01 and 02 of
> the WG draft I believe it "magically" changed. I remember asking about
> the motivation but I cannot recall an answer. My guess is that 25ms is
> very few packets in common residential broadband access networks and
> the algorithm might not quite work that well in those settings _today_.
> After some debate we ended up accepting 100 ms as a maximum. The
> problem is that going away from 100 ms in practice is that (assuming
> more than one app adopts LEDBAT congestion control) the one app that
> yields the most will get the least throughput, making anything less
> than 100 ms really unattractive in a competitive environment. So while
> I am personally OK with the compromise we achieved in the end, I am not
> happy about the lack of motivation. I am mildly optimistic that it is
> based on experience in the field rather than making the existing
> implementation at the tim
> >     atch the spec.
> 
> I searched the email archives and didn't see anything discussing it
> (though I might have missed it) or discussing interaction with VoIP
> (other than that one paper, which also showed the sensitivity to the
> allowed delay and the advantage of a user willing to accept longer
> delays, plus how latecomers could mis-read the buffer state.
> 
> The problem is that a 100ms-delay-scavenger algorithm like this
> "poisons the well" for any application that desires/needs lower delay.
> That's why I believe there are only two reasonable targets: 0 (drained
> queues) and full queues (assuming AQM isn't implemented to keep queues
> low).

I think worrying about a poisoned well is a little late with loss-based congestion control being deployed.
 
> I don't think this is just a theoretical problem, I think it's a very
> serious issue, which if LEDBAT gets used a lot will cause a lot of
> problems.  Perhaps it's *better* than old-style saturating bittorrent
> flows, in that VoIP will be possible without shutting down bittorrent,
> but that doesn't mean it's good, and the perception that bittorrent
> doesn't break other apps with the new protocols will encourage people
> to leave it running - and depending on the vagaries of bittorrent, it
> might be fine when you start the call and then slam you.  I'm
> especially worried about OS's and apps using it for background update
> transfers with no user control or knowledge, etc.

Well, this reads a bit too dramatic for my taste. LEDBAT typically comes with the app so you're a bit more agile regarding the congestion control parameterization (and even the implementation as the BitTorrent folks have shown). BTW, as long as update services do not use the uplink capacity of customers, I don't see much of a problem (assuming we agree that the biggest problem is home gateways). Not sure how BITS compares in all of this either. In either case it beats TCP and that is used without the users' knowledge, too. The best you could probably do is design better home gateways which would solve many of the problems we see today (the better ones actually today implement traffic shaping with really good results, probably better than any end-to-end congestion control algorithm).

Best, 	

Rolf

> 
> --
> Randell Jesup
> [e-mail]
>