On 4/24/2012 4:35 PM, Rolf Winter wrote:

We know when faced with deep buffers and large loss-based flow, a delay
flow will lose or have to transition to loss-based and live with delay
(see Cx-TCP).  We also know that in practice, the (residential)
bottleneck links are almost always the access link (DSL, fiber, etc) or
sometimes the WiFi connection. Corporate/educational can be a bit
different, but there's a better chance of AQM or service-based traffic
shaping there.

We can deal (mostly) with fighting with TCP and expected it.  We didn't
expect scavenger protocols to be pumping the queues up when TCP is idle
or bursty.

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.

I note that LEDBAT is now in Linux and MacOS, so it's not just in
application code anymore, and app developers (even OS developers) may
assume it's safe to blindly use without user involvement.  (And even if
informed, assuming users understand the interaction of protocols is ...
a stretch.)

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.

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 believe RRTCC could cover a fair amount of of the goals of LEDBAT with alternate tunings, for example.

Let me be clear: *if* widespread LEDBAT use, especially by "background"/non-user-visible apps will cause major disruption of VoIP flows on the net (and in particular for flows from within the same residence or enterprise), then there's a real problem with encouraging deployment. If it does not, then the issue is minor. I also believe that we do not know the answer to this question currently, though I believe the answer it is that it will cause significant delay and quality loss, and we have some evidence to that effect.

Also (and I haven't checked this yet): how does LEDBAT respond to AQM? From telecom-paristech.fr:

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)

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.

-- 
Randell Jesup
randell-ietf@jesup.org