From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 36E8E21F2B7 for ; Tue, 24 Feb 2015 08:34:46 -0800 (PST) Received: from srichardlxp2 ([46.245.200.65]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LbdE3-1XgkPZ07pr-00lAZ2; Tue, 24 Feb 2015 17:34:42 +0100 Message-ID: From: "Richard Scheffenegger" To: "sahil grover" , "Jonathan Morton" References: Date: Tue, 24 Feb 2015 17:33:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01D05057.FE8A55C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Provags-ID: V03:K0:zsBCiQL8h02kxyLzCaQ/GreotRwzleXNjvTu1V6CElZVumsjchR 8g4ZL4oYVRp6q4jrRvryJ8/+Ltl8j8DOypvVRdxAOe9XRwzfaEMZVWYmeBU3CgTQyLjQ1tC Lt7g/EW7PKNVv7kA5G9aGKTdl3HeJaNTxdhE/cVvg/nfOMomECJ6uVhPM4dNXPlvMmy6kSy OsuTJj7bUF2XCVfEdF2kw== X-UI-Out-Filterresults: notjunk:1; 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 16:35:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01D05057.FE8A55C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 -----=20 From: sahil grover=20 To: Jonathan Morton=20 Cc: codel@lists.bufferbloat.net=20 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 ------=_NextPart_000_0030_01D05057.FE8A55C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sahil.,
 
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; Second, Codel (in it's = plain form)=20 does drop/mark on dequeue, while RED drops/marks on enqueue.=20 This means, that [TCP] congestion control loop is much quicker with = Codel=20 over RED; thus the reaction by the sender will probably be timely and = relevant=20 for that congestion epoch.  With RED; the congestion signal (that = lost=20 packet) has to traverse the filled-up buffer first, thus the control = loop time=20 is much larger (includes the instantaneous queue length of the buffer) - = and is=20 further delayed by the averaging going on.
 
Codel, by design, doesn't need to be = tuned=20 specifically for one particular drain rate (bandwidht) of the queue - = unlike=20 RED; So it adjusts much better to variable bandwidth MACs (Wifi,=20 DOCSIS).
 
I've been told, that RED is easier to = implement in=20 HW due to that action being all done on enqueue. With PIE, there exists = another=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.
 
 
If you follow the AQM work in IETF, = there is strong=20 consensus steer to these more modern AQMs.
 
Best regards,
  Richard
 
 
----- 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 = Morton <chromatix99@gmail.com> wrote:

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

Codel not only performs better than an ideally = configured 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/list= info/codel
------=_NextPart_000_0030_01D05057.FE8A55C0--