<div dir="ltr"><div class="gmail_default" style="font-size:small">Keith,</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 4:19 PM, Keith Winstein <span dir="ltr"><<a href="mailto:keithw@mit.edu" target="_blank">keithw@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank, Dave.<div><br></div><div>We have a Web site with more info, a talk, and source code (<a href="http://alfalfa.mit.edu" target="_blank">http://alfalfa.mit.edu</a>) if anybody is interested.</div>
<div><br></div><div>Something that may interest folks here is that we compared Sprout-over-unlimited-buffer with TCP-Cubic-over-CoDel on these cellular-type links. That is, a scenario where the network operators implemented CoDel inside the LTE/UMTS/1xEV-DO base station (for the downlink) and the phone manufacturers implemented CoDel inside the "baseband" chip for the uplink.<br>


<br>Bottom line results is that for the case where a cellular user can control all their own flows, it's roughly a wash. To a first approximation, you can fix bufferbloat on a cellular network *either* by putting CoDel inside the base station and baseband chip (and otherwise running the same endpoint TCP), *or* by changing the endpoints but leaving the base station and baseband chip unmodified.</div>
</blockquote><div><br></div><div class="gmail_default" style="font-size:small">Did you compare with fq_codel?  None of us (Van included) advocate CoDel by itself.</div><div class="gmail_default" style="font-size:small"></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>Obviously we benefit dramatically from the per-user queues of the cellular network. By contrast, in a typical house with a bufferbloated cable modem where one user can cause big delays for everybody else, you can't fix bufferbloat by fixing just one endpoint. We will have some results soon on whether you can fix it by fixing all the endpoints (but still leaving the "bloated" gateway intact).</div>
</blockquote><div><br></div><div class="gmail_default" style="font-size:small">Yup, per user queues help.  But those per-user queues can be extremely large; you can hurt yourself as soon as you want to mix your WebRTC kind of traffic with anything else.</div>
<div><br></div><div class="gmail_default" style="font-size:small">Jim</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br></div><div>Cheers,</div><div>Keith</div><div class="HOEnZb"><div class="h5"><div><br></div><div><div class="gmail_quote">On Wed, Jul 10, 2013 at 3:30 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I haven't been paying a lot of attention to rmcat and webrtc until<br>
recently, although I'd had a nice discussion with keith on it a while<br>
back..<br>
<br>
this particular thread sums up some interesting issues on that front.<br>
<br>
<a href="http://www.ietf.org/mail-archive/web/rmcat/current/msg00390.html" target="_blank">http://www.ietf.org/mail-archive/web/rmcat/current/msg00390.html</a><br>
<span><font color="#888888"><br>
--<br>
Dave Täht<br>
<br>
Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Codel mailing list<br>
<a href="mailto:Codel@lists.bufferbloat.net">Codel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/codel" target="_blank">https://lists.bufferbloat.net/listinfo/codel</a><br>
<br></blockquote></div><br></div></div>