<div>Also nice:</div><div><br></div><a href="http://perso.rd.francetelecom.fr/oueslati/Pub/xp-hpsr.pdf">http://perso.rd.francetelecom.fr/oueslati/Pub/xp-hpsr.pdf</a><div><br></div><div>I'd been just down the street from you (at LINCS) multiple times in the past year. Pouring through the rest of your canon now...</div>
<div><br></div><div>as for your referenced:</div><div><br></div><div><a href="http://www.tlc-networks.polito.it/oldsite/muscariello/papers/Kortebi-f18.pdf">http://www.tlc-networks.polito.it/oldsite/muscariello/papers/Kortebi-f18.pdf</a><br>
<div><br></div><div>It is unfortunate that Stochastic Fair Queueing and and "Start Time Fair Queuing" have an overloaded acronym. But I tend to agree that "flow" is the word we should be using rather than "fair". Good stuff, tho, and shows a potential hardware implementation....</div>
<div><br></div><div>As for codel vs "longest queue drop" - codel is tcp friendly, and with the early signalling can drop from the head of multiple queues where they are exceeding the target delay rather than just the largest one. And it drops gently (being tcp friendly), working on end to end signaling rather than attacking the immediate source of congestion.</div>
<div><br></div><div>The "drop from longest queue" IS an error out condition in fq_codel, but it's rarely hit (and rather cpu intensive when it is hit) as queue length is managed long beforehand by codel. </div>
<div><br></div><div>I do regard admission control and slow start behavior as something of an ongoing problem and more work on this front is indicated.</div><div><br></div><div>I just gave a talk on some of this at stanford ( <a href="http://netseminar.stanford.edu">http://netseminar.stanford.edu</a> )</div>
<div><br></div><div>I just finished reading your 1999 paper. Very, very nice. </div><div><br></div><div><a href="http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf">http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf</a></div>
<div><br></div><div>I will update my fq_codel slides to point to the 1996 paper as to 'first implementation" of head drop, but now that I know another phrase for it, perhaps it goes back even further than this?</div>
<div><span style="font-size:9pt;font-family:Times"><br></span></div><div>"<span style="font-size:9pt;font-family:Times">T. Lakshman, A. Neidhart, and T. Ott, “The drop-from-front
strategy in TCP over ATM and its interworking with other
control features,” in </span><span style="font-size:9pt;font-family:Times;font-style:italic">Proceedings of IEEE INFOCOM’96, </span><span style="font-size:9pt;font-family:Times">(San
Francisco, CA), pp. 1242–1250, 1996." </span></div><div><span style="font-size:9pt;font-family:Times"><br></span></div><div><span style="font-size:9pt;font-family:Times"><br></span></div><div>Lastly, from the conclusion:</div>
<div><br></div><div>
<div class="column">
<p><span style="font-size:12.000000pt;font-family:'Times'">"When TCP has to compete with more aggressive
sources or in asymmetric networks, with a perpetu-
ally congested reverse path , FCFS-RED, FQ-RED
or any other global dropping policy perform very
poorly.
</span></p>
<p><span style="font-size:12.000000pt;font-family:'Times'">The decision of whether to incur the expense of
fair queueing depends on the performance and sta-
bility expected of the system. We have shown that
by using fair queueing in combination with appro-
priate packet dropping (and not by fair queueing
alone) performance and fairness is enhanced in any
case but particularly in situations that involve loss
insensitive, non-responsive flows.
</span></p>
<p><span style="font-size:12.000000pt;font-family:'Times'">If the simplicity of FCFS is to be traded for the
higher stability and fairness of fair queueing, then
there is little reason to persist with using a global
dropping strategy. For little additional cost, ALQD
can complement an efficient WFQ scheduling im-
plementation to provide good fairness and provide
nearly perfect flow isolation and protection."</span></p><p><span style="font-size:12.000000pt;font-family:'Times'">After running more traffic than I care to think about through qfq+codel, fq_codel and sfqred... agree with the experimental methods in the paper... and with the conclusion. Nice work. Sure wish I'd known of it a while ago...</span></p>
<p><span style="font-size:12.000000pt;font-family:'Times'"> </span></p>
</div></div><div><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 4:29 AM, James Roberts <span dir="ltr"><<a href="mailto:James.Roberts@inria.fr" target="_blank">James.Roberts@inria.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have not been following Bufferbloat but a colleague forwarded to me the latest post from Dave Täht about FQ_Codel. It is good to see the virtues of fair queuing are being rediscovered.<br>
<br>
I think the work by Suter and co-authors on FQ in high capacity routers is particularly relevant:<br>
<br>
B. Suter, T. Lakshman, D. Stiliadis, A. Choudhury, Buffer Management Schemes<br>
for Supporting TCP in Gigabit Routers with Per-Flow Queuing, IEEE Journal in<br>
Selected Areas un Communications, August 1999. (<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=772451" target="_blank">http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=772451</a>)<br>
<br>
They may have been the first to introduce "head drop". Actually they advocated dropping from the front of the flow queue with longest backlog (FQ_LQD). I am not sure why a more sophisticated AQM, like RED, ARED or Codel, is better than longest queue drop.<br>
<br>
Another advantage of FQ_Codel highlighted in the report by Toke Høiland-Jørgensen (notified on the list) is to give priority to packets of newly active flows. This idea was already proposed in our papers:<br>
<br>
A. Kortebi, S. Oueslati and J. Roberts. Cross-protect: implicit service differentiation and admission control, IEEE HPSR 2004, Phoenix, USA, April 2004.<br>
A. Kortebi, S. Oueslati, J. Roberts. Implicit service differentiation using Deficit Round Robin, Proceedings of ITC 19, Beijing, August 2005.<br>
<br>
I have long been advocating per flow fairness as the basis of effective traffic control so I hope you won't mind me recalling this prior work.<br>
<br>
Jim Roberts<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <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>
</div></div>