From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B5BE821F295 for ; Tue, 24 Feb 2015 09:29:43 -0800 (PST) Received: by labgm9 with SMTP id gm9so27475269lab.2 for ; Tue, 24 Feb 2015 09:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=avl4dQVdGfb0BNcYydySQGiu00dST9VkPSpiIYvcyr0=; b=sb5THrxm3Y+tGV3IOcmVPRouJbd8R9os+sp0ekIKL+bGybBboYUgzORzPVRO5S9Tix slnTlNZRSnQ9CT8KegNxB2IayTL48TfQ8n2DsxRb40Fyf3Eqqa56B/MIpf0XOW7eepl4 ZKw3bB3Rh9c2Q0Vf/FeAaT/WAWaL4mYXCxDGNho3ilIbHAFuGToTEWsrg596tRC0/9Ri eBmfrwNVSlXpv9se7G0mleTcb58RSnMj3tm8Vrb8KmK5kITox/P8g+pnciu9ArLp75ZY JC0Ya5//IJLNc5a4ubkqyHNLajPZ7zhR8fEAv/v03iLNyvso3tesGxPrE3vn8GYoj9V+ cZHw== MIME-Version: 1.0 X-Received: by 10.112.118.211 with SMTP id ko19mr15406846lbb.19.1424798981384; Tue, 24 Feb 2015 09:29:41 -0800 (PST) Received: by 10.25.147.75 with HTTP; Tue, 24 Feb 2015 09:29:41 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 09:29:41 -0800 Message-ID: From: sahil grover To: Richard Scheffenegger , wes@mti-systems.com Content-Type: multipart/alternative; boundary=047d7b8746c2296f30050fd8ddc0 Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. 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, 24 Feb 2015 17:30:12 -0000 --047d7b8746c2296f30050fd8ddc0 Content-Type: text/plain; charset=UTF-8 Thanks a lot Jonathan,Eddy and Richard. With the help of you people i have cleared many concepts. But still one point is not clear. Richard Sir you said that Codel is better in notifying congestion to TCP senders. But Sir how,i know codel does it at dequeue stage while RED does at enqueue stage. The thing is congestion signal has to traverse the buffer. Then how does it make difference that whether it is at enqueue or dequeue.i mean how it is quicker with codel? On Tue, Feb 24, 2015 at 8:33 AM, Richard Scheffenegger wrote: > Sahil., > > Codel tries to address the problems that RED couldn't; First, the input > signal into the algorithm (sojourn time vs. average queue depth) is of a > different quality; Second, Codel (in it's plain form) does drop/mark on > dequeue, while RED drops/marks on enqueue. This means, that [TCP] > congestion control loop is much quicker with Codel over RED; thus the > reaction by the sender will probably be timely and relevant for that > congestion epoch. With RED; the congestion signal (that lost packet) has > to traverse the filled-up buffer first, thus the control loop time is much > larger (includes the instantaneous queue length of the buffer) - and is > further delayed by the averaging going on. > > Codel, by design, doesn't need to be tuned specifically for one particular > drain rate (bandwidht) of the queue - unlike RED; So it adjusts much better > to variable bandwidth MACs (Wifi, DOCSIS). > > I've been told, that RED is easier to implement in HW due to that action > being all done on enqueue. With PIE, there exists another AQM that tries to > re-use the hw engines that exist for RED, but the control algorithms try to > use a different input signal - making the best of that. > > > If you follow the AQM work in IETF, there is strong consensus steer to > these more modern AQMs. > > Best regards, > Richard > > > > ----- Original Message ----- > *From:* sahil grover > *To:* Jonathan Morton > *Cc:* codel@lists.bufferbloat.net > *Sent:* Tuesday, February 24, 2015 5:20 PM > *Subject:* Re: [Codel] why RED is not considered as a solution to > bufferbloat. > > So we can say Codel is better than other AQM??? > > On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Morton > wrote: > >> Simply put, RED is a very old algorithm, one of the first viable AQM >> algorithms. However, it proved to be so difficult to configure properly >> that almost nobody uses it, even though many carrier grade routers >> implement it. >> >> Codel not only performs better than an ideally configured RED, but is far >> easier to configure. This makes it much more deployable. >> >> - Jonathan Morton >> > > ------------------------------ > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > > --047d7b8746c2296f30050fd8ddc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot Jonathan,Eddy and Richard.
With the help = of you people i have cleared many concepts.
But still one point i= s not clear.
Richard Sir you said that Codel is better in notifyi= ng congestion to TCP senders.
But Sir how,i know codel does it at= dequeue stage while RED does at enqueue stage.
The thing is =C2= =A0congestion signal has to traverse the buffer.
Then how doe= s it make difference that whether it is at enqueue or dequeue.i mean how it= is quicker with codel?



<= /div>

On Tue, Feb = 24, 2015 at 8:33 AM, Richard Scheffenegger <rscheff@gmx.at> wro= te:
Sahil.,
=C2=A0
Codel tries to address the problems that RED=20 couldn't; First, the input signal into the algorithm (sojourn time vs. = average=20 queue depth) is of a different quality;=C2=A0Second, Codel (in it's pla= in form)=20 does drop/mark on dequeue, while RED=C2=A0drops/marks on enqueue.=20 This=C2=A0means, that [TCP] congestion control loop is much quicker with Co= del=20 over RED; thus the reaction by the sender will probably be timely and relev= ant=20 for that congestion epoch.=C2=A0 With RED; the congestion signal (that lost= =20 packet) has to traverse the filled-up buffer first, thus the control loop t= ime=20 is much larger (includes the instantaneous queue length of the buffer) - an= d is=20 further delayed by the averaging going on.
=C2=A0
Codel, by design, doesn't need to be tuned=20 specifically for one particular drain rate (bandwidht) of the queue - unlik= e=20 RED; So it adjusts much better to variable bandwidth MACs (Wifi,=20 DOCSIS).
=C2=A0
I've been told, that RED is easier to impleme= nt in=20 HW due to that action being all done on enqueue. With PIE, there exists ano= ther=20 AQM that tries to re-use the hw engines that exist for RED, but the control= =20 algorithms try to use a different input signal - making the best of=20 that.
=C2=A0
=C2=A0
If you follow the AQM work in IETF, there is stro= ng=20 consensus steer to these more modern AQMs.
=C2=A0
Best regards,
=C2=A0 Richard
=C2=A0
=C2=A0
----- Original Message -----
From:=20 sahil=20 grover
Sent: Tuesday, February 24, 2015 5:= 20=20 PM
Subject: Re: [Codel] why RED is not= =20 considered as a solution to bufferbloat.

So we can say Codel is better than other AQM???

On Tue, Feb 24, 2015 at 9:24 PM, Jonathan Mort= on <chromatix99@gmail.com> wrote:

Simply put, RED is a very old algorithm, one of the firs= t viable=20 AQM algorithms. However, it proved to be so difficult to configure prop= erly=20 that almost nobody uses it, even though many carrier grade routers impl= ement=20 it.

Codel not only performs better than an ideally configure= d RED,=20 but is far easier to configure. This makes it much more deployable.

=

- Jonathan=20 Morton


_______________________________________________
Codel mailing= =20 list
= Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/c= odel


--047d7b8746c2296f30050fd8ddc0--