<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 4/24/2012 4:35 PM, Rolf Winter wrote:
<blockquote
cite="mid:791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd"
type="cite">
<blockquote type="cite">
<pre wrap="">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.)
</pre>
</blockquote>
<pre wrap="">
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". </pre>
</blockquote>
<br>
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.<br>
<br>
So if this "breaks" the network, we have a problem. <br>
<br>
<blockquote
cite="mid:791AD3077F94194BB2BDD13565B6295D2509E0F0@Polydeuces.office.hd"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
I believe RRTCC could cover a fair amount of of the goals of LEDBAT
with alternate tunings, for example.<br>
<br>
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.<br>
<br>
Also (and I haven't checked this yet): how does LEDBAT respond to
AQM? From telecom-paristech.fr:<br>
<blockquote>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)
<br>
</blockquote>
<a class="moz-txt-link-freetext" href="http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf">http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf</a><br>
<br>
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.<br>
<br>
<pre class="moz-signature" cols="72">--
Randell Jesup
<a class="moz-txt-link-abbreviated" href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a></pre>
</body>
</html>