<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Am I missing something??????<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill VerSteeg<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] <b>On Behalf Of </b>Randell Jesup<br><b>Sent:</b> Tuesday, April 24, 2012 3:02 PM<br><b>To:</b> Rolf Winter<br><b>Cc:</b> Randell Jesup; ledbat@ietf.org; rtp-congestion@alvestrand.no<br><b>Subject:</b> Re: [R-C] [ledbat] LEDBAT vs RTCWeb<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 4/24/2012 4:35 PM, Rolf Winter wrote: <o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>We know when faced with deep buffers and large loss-based flow, a delay<o:p></o:p></pre><pre>flow will lose or have to transition to loss-based and live with delay<o:p></o:p></pre><pre>(see Cx-TCP). We also know that in practice, the (residential)<o:p></o:p></pre><pre>bottleneck links are almost always the access link (DSL, fiber, etc) or<o:p></o:p></pre><pre>sometimes the WiFi connection. Corporate/educational can be a bit<o:p></o:p></pre><pre>different, but there's a better chance of AQM or service-based traffic<o:p></o:p></pre><pre>shaping there.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>We can deal (mostly) with fighting with TCP and expected it. We didn't<o:p></o:p></pre><pre>expect scavenger protocols to be pumping the queues up when TCP is idle<o:p></o:p></pre><pre>or bursty.<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>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.<o:p></o:p></pre><p class=MsoNormal><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><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>I note that LEDBAT is now in Linux and MacOS, so it's not just in<o:p></o:p></pre><pre>application code anymore, and app developers (even OS developers) may<o:p></o:p></pre><pre>assume it's safe to blindly use without user involvement. (And even if<o:p></o:p></pre><pre>informed, assuming users understand the interaction of protocols is ...<o:p></o:p></pre><pre>a stretch.)<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>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". <o:p></o:p></pre><p class=MsoNormal><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><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Note that no routers are likely to recognize rtcweb traffic as VoIP<o:p></o:p></pre><pre>since the signaling is opaque and application-dependant, so ALGs and<o:p></o:p></pre><pre>the like have nothing to work against. It would have to 'guess' that<o:p></o:p></pre><pre>the packet stream leading byte pattern and STUN/ICE traffic signified<o:p></o:p></pre><pre>use of the port for VoIP. Eventually they may learn, but it will take<o:p></o:p></pre><pre>years.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I stand by the contention this is a real, significant problem which<o:p></o:p></pre><pre>could get far worse if non-user-centric services start using LEDBAT.<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>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.<o:p></o:p></pre><p class=MsoNormal><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:<o:p></o:p></p><p class=MsoNormal>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) <o:p></o:p></p><p class=MsoNormal><a 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><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Randell Jesup<o:p></o:p></pre><pre><a href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a><o:p></o:p></pre></div></body></html>