[R-C] [ledbat] LEDBAT vs RTCWeb

Wed Apr 25 01:23:35 CEST 2012

I am a bit confused by the last paragraph. I understand why one would
implement active queue management algorithms in middleboxes like
cable/DSL modems, but I am not sure how AQM on a set top box would help
with bufferbloat. I guess I could come up with some very narrow cases in
which an endpoint would benefit from advance buffer management
techniques for self generated competing flows, but this would be very
artificial and of no use in the real world. 

Am I missing something??????

Bill VerSteeg

From: rtp-congestion-bounces at alvestrand.no
[mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Randell Jesup
Sent: Tuesday, April 24, 2012 3:02 PM
To: Rolf Winter
Cc: Randell Jesup; ledbat at ietf.org; rtp-congestion at alvestrand.no
Subject: Re: [R-C] [ledbat] LEDBAT vs RTCWeb

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 at jesup.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120424/c88bd792/attachment-0001.html>