From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 88B8221F1B5; Tue, 12 Feb 2013 07:01:29 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so150806iaj.6 for ; Tue, 12 Feb 2013 07:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oWFUx6nwGcrk5ECWuZFuKOXUtm5mKII5jWHgoZgcKHY=; b=BxmTZAw/bUtNHxt0AXkzAa794DP+KyZ6T8udk+6tUHwTMPcWzUiv/drbjVav5BwU0o KKaVcd5bsYZ47ec5Of09Ap9oJJ8j0ifC1OghZR8ctOS8qgQk6AaZB97jmim3iYBvAFIE cqHXWqrGTIHoxFg1MD4Jl25nWZOsi0mfDXFi4g3wIDpdXAB1C2r/Floqobq4iDm57KXo /6KtptWwSswC0P8Pdzks51/b/Qquib/ykUNLr9jLUuhHlKt1zR38WKW9kTD4CfxEdgbQ CwX0hncEAFN3yHqtj9q76CwVogukzvjlKFJDoGuGpCGpvVtCq375Q797GtCXO0n9N118 OjYw== MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr3775014igc.96.1360681288557; Tue, 12 Feb 2013 07:01:28 -0800 (PST) Received: by 10.64.135.39 with HTTP; Tue, 12 Feb 2013 07:01:28 -0800 (PST) In-Reply-To: <88264AA4-1200-4078-8A94-41D814899C8F@inria.fr> References: <88264AA4-1200-4078-8A94-41D814899C8F@inria.fr> Date: Tue, 12 Feb 2013 10:01:28 -0500 Message-ID: From: Dave Taht To: James Roberts Content-Type: multipart/alternative; boundary=14dae9340fe1db652b04d5884cd2 Cc: codel@lists.bufferbloat.net, bloat Subject: Re: [Codel] FQ_Codel v. FQ_LQD X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:01:30 -0000 --14dae9340fe1db652b04d5884cd2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Also nice: http://perso.rd.francetelecom.fr/oueslati/Pub/xp-hpsr.pdf 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... as for your referenced: http://www.tlc-networks.polito.it/oldsite/muscariello/papers/Kortebi-f18.pd= f 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.... 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. 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. I do regard admission control and slow start behavior as something of an ongoing problem and more work on this front is indicated. I just gave a talk on some of this at stanford ( http://netseminar.stanford.edu ) I just finished reading your 1999 paper. Very, very nice. http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf 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? "T. Lakshman, A. Neidhart, and T. Ott, =93The drop-from-front strategy in T= CP over ATM and its interworking with other control features,=94 in Proceeding= s of IEEE INFOCOM=9296, (San Francisco, CA), pp. 1242=961250, 1996." Lastly, from the conclusion: "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. 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. 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." 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..= . On Tue, Feb 12, 2013 at 4:29 AM, James Roberts wrot= e: > I have not been following Bufferbloat but a colleague forwarded to me the > latest post from Dave T=E4ht about FQ_Codel. It is good to see the virtue= s of > fair queuing are being rediscovered. > > I think the work by Suter and co-authors on FQ in high capacity routers i= s > particularly relevant: > > B. Suter, T. Lakshman, D. Stiliadis, A. Choudhury, Buffer Management > Schemes > for Supporting TCP in Gigabit Routers with Per-Flow Queuing, IEEE Journal > in > Selected Areas un Communications, August 1999. ( > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D772451) > > 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. > > Another advantage of FQ_Codel highlighted in the report by Toke > H=F8iland-J=F8rgensen (notified on the list) is to give priority to packe= ts of > newly active flows. This idea was already proposed in our papers: > > A. Kortebi, S. Oueslati and J. Roberts. Cross-protect: implicit service > differentiation and admission control, IEEE HPSR 2004, Phoenix, USA, Apr= il > 2004. > A. Kortebi, S. Oueslati, J. Roberts. Implicit service differentiation > using Deficit Round Robin, Proceedings of ITC 19, Beijing, August 2005. > > 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. > > Jim Roberts > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae9340fe1db652b04d5884cd2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Also nice:

http://perso.rd.francetelecom.fr/oueslati/Pu= b/xp-hpsr.pdf

I'd been just down the street from= you (at LINCS) multiple times in the past year. Pouring through the rest o= f your canon now...

as for your referenced:

http://www.tlc-networks.polito.it/oldsite/muscariello/papers/Korteb= i-f18.pdf

It is unfortunate that Stochastic Fair Queueing and and= "Start Time Fair Queuing" have an overloaded acronym.=A0But I te= nd to agree that "flow" is the word we should be using rather tha= n "fair". Good stuff, tho, and shows a potential hardware impleme= ntation....

As for codel vs "longest queue drop" - codel = is tcp friendly, and with the early signalling can drop from the head of mu= ltiple queues where they are exceeding the target delay rather than just th= e largest one. And it drops gently (being tcp friendly), working on end to = end signaling rather than attacking the immediate source of congestion.

The "drop from longest queue" IS an error out= condition in fq_codel, but it's rarely hit (and rather cpu intensive w= hen it is hit) as queue length is managed long beforehand by codel.=A0

I do regard admission control and slow start behavior a= s something of an ongoing problem and more work on this front is indicated.=

I just gave a talk on some of this at stanford (= =A0http://netseminar.stanford.ed= u )

I just finished reading your 1999 paper. Very, very nic= e.=A0


I will update my fq_codel slides to point to the 1996 p= aper as to 'first implementation" of head drop, but now that I kno= w another phrase for it, perhaps it goes back even further than this?

= "T. Lakshman, A. Neidh= art, and T. Ott, =93The drop-from-front strategy in TCP over ATM and its interworking with other control features,=94 in Proceedings of IEEE INFOCOM=9296, (San Francisco, CA), pp. 1242=961250, 1996." =A0


Lastly, from the co= nclusion:

=09 =09 =09

&qu= ot;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.

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.

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."

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 conclusi= on. Nice work. Sure wish I'd known of it a while ago...

=A0


On Tue, Feb 12, 2013 at 4= :29 AM, James Roberts <James.Roberts@inria.fr> wrote:
I have not been following Bufferbloat but a colleague forwarded to me the l= atest post from Dave T=E4ht about FQ_Codel. It is good to see the virtues o= f fair queuing are being rediscovered.

I think the work by Suter and co-authors on FQ in high capacity routers is = particularly relevant:

B. Suter, T. Lakshman, D. Stiliadis, A. Choudhury, Buffer Management Scheme= s
for Supporting TCP in Gigabit Routers with Per-Flow Queuing, IEEE Journal i= n
Selected Areas un Communications, August 1999. (h= ttp://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D772451)<= br>
They may have been the first to introduce "head drop". Actually t= hey advocated dropping from the front of the flow queue with longest backlo= g (FQ_LQD). I am not sure why a more sophisticated AQM, like RED, ARED or C= odel, is better than longest queue drop.

Another advantage of FQ_Codel highlighted in the report by Toke H=F8iland-J= =F8rgensen (notified on the list) is to give priority to packets of newly a= ctive flows. This idea was already proposed in our papers:

A. Kortebi, S. Oueslati and J. Roberts. Cross-protect: implicit service dif= ferentiation and admission control, =A0IEEE HPSR 2004, Phoenix, USA, April = 2004.
A. Kortebi, S. Oueslati, J. Roberts. Implicit service differentiation using= Deficit Round Robin, =A0Proceedings of ITC 19, Beijing, August 2005.

I have long been advocating per flow fairness as the basis of effective tra= ffic control so I hope you won't mind me recalling this prior work.

Jim Roberts
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/codel



--
Dave T=E4ht<= br>
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/s= ubscribe.html=20
--14dae9340fe1db652b04d5884cd2--