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

[Rolf Winter <[e-mail]>]

> 	Here is where you lose me a bit. How do you "fight" TCP and its
> queue build-up exactly. I don't think we talk about protocols with the
> same design goals, are we. One of LEDBAT's design goals e.g. is to use
> all available bandwidth.
> 
> 
> Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0,
> b) use a 'fair' share of bandwidth (all available if the other flows
> don't use all the available bandwidth).  Low delay generally takes
> precedence over bandwidth, though eventually we hit a wall and can't
> reasonably reduce bandwidth more.
> 
> The design goals are not identical to LEDBAT; but these protocols need
> to share the network "well" with each other and TCP (and inflexible UDP
> flows like classic VoIP).  TCP is a given (unfortunately), and drop-
> tail routers with deep buffers are also a given (very unfortunately,
> especially with TCP).
> 
> We can't stop TCP from grabbing all buffers; though there may be
> limited ability to "knock TCP back" some periodically when there are a
> small number of competing TCP flows, at the costs of delay bursts - but
> that probably isn't practical (a usable experience) for users.

Exactly. You cannot. Not sure what's behind "knock TCP back" but as you say you'll add delay which pretty much seems to violate your own design goals. It generally becomes difficult for me to discuss something that I haven't seen a spec of. Is there a document that outlines how this congestion control algorithm actually works? 

> 	And I think it is good that LEDBAT sees some deployment. It is an
> experimental congestion control algorithm. These experiments will
> provide us with good feedback and we might need to revisit some design
> decisions. There are millions of deployed LEDBAT-enabled clients out
> there and unfortunately the only thing we know about this "experiment"
> is that the experimenters have assured us that LEDBAT was deployed with
> "good success".
> 
> 
> Millions != experiments.  This is wide-scale deployment, and implying
> it isn't is misleading (as will deployment of WebRTC).  And
> implementation in core OS/X and Linux one assumes will lead to use by
> OS functions and applications such as cloud file backup, app update,
> etc.
> 
> So if this "breaks" the network, we have a problem.

As far as the IETF goes the congestion control spec is experimental. I also think the spec does a decent job when it comes to underlying assumptions made such as FIFO queues. Also it recommends to use AQM and acknowledges the fact that its behavior will look much more like TCP when AQM is employed etc. The way this work came to the IETF was obviously after the fact, but in terms of congestion control this is not without precedent. That doesn't mean the IETF should elevate every widely deployed technology to proposed standard but having it documented, having expert reviews and encouraging experiments is a good thing. And that these "things" can and do happen is just due to the way the Internet was built. When you build your congestion control algorithm you shouldn't expect that you'll only have to deal with TCP and that it will actually behave the way it does today for eternity.

> 
> 		Note that no routers are likely to recognize rtcweb traffic
> as VoIP
> 		since the signaling is opaque and application-dependant, so
> ALGs and
> 		the like have nothing to work against.  It would have to
> 'guess' that
> 		the packet stream leading byte pattern and STUN/ICE traffic
> signified
> 		use of the port for VoIP.  Eventually they may learn, but
> it will take
> 		years.
> 
> 		I stand by the contention this is a real, significant
> problem which
> 		could get far worse if non-user-centric services start
> using LEDBAT.
> 
> 
> 	Maybe, but the alternative protocol that these apps you describe
> above can use is TCP. I remain unconvinced that TCP makes the problem
> less severe than LEDBAT would.
> 
> 
> I think this is a false dichotomy, in that there are other choices for
> such applications, such as TFRC, RRTCC (which we're defining), TCP-
> Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to
> loss-based fair sharing when faced with TCP - modifying it can probably
> lead to it dropping to low BW when competing) and for that matter
> LEDBAT itself (or a variant thereof) with different tunings.

I think we disagree here. I take that you're defining RRTCC just now so a couple of years back that wasn't available. When you talk about any TCP-flavor and not just about the congestion control part you are correct in theory, however in practice you're not since you'll need to wait till all OS folks have implemented it. Clearly that is not an option if you want to roll out and sell your app today.
 
> I believe RRTCC could cover a fair amount of of the goals of LEDBAT
> with alternate tunings, for example.

A pointer to the spec would be highly appreciated.

> we have some evidence to that effect.

Data? A pointer would be nice.

> 	The experimental work in [ITC22] exploits instead a own
> implementation and points that LEDBAT may not work as expected (and
> actually might be needed) in case active queue management techniques
> AQM are applied in user modems (the study also suggests AQM to become a
> default practice in set-top-box devices)

I love it when people point to papers that I have co-authored ;) We haven't looked at set-top-boxes but home gateways. And indeed the ones that cost a little more come with useable default settings for traffic shaping where the combo TCP BitTorrent plus Voice beats LEDBAT plus Voice (by miles). But as you stated earlier, this relies on the fact that the box knows how to tell them apart. The downside is that they don't do congestion control obviously. So if you intend to send lot's of data you'll still need to do that.

> 
> http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf
> 
> It seems like AQM causes LEDBAT to promote to behavior similar to TCP,
> but with low delay.  Since it still seems fair, this is ok, but it's no
> longer a background or scavenger flow, and applications using it need
> to be aware they can impact "foreground" flows if AQM is in play.
> Perhaps applications need to be given awareness when LEDBAT detects
> active AQM (if it can), and there's no "scavenger" CC algorithm for AQM
> that I know of.

And the document makes that clear and I am not sure LEDBAT actually can detect AQM.


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