From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A428B21F301 for ; Wed, 25 Feb 2015 01:18:07 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YQY6W-0002xm-FE; Wed, 25 Feb 2015 10:18:04 +0100 Received: from mail-ex14.exprod.uio.no ([129.240.120.76]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YQY6V-0000LA-AH; Wed, 25 Feb 2015 10:18:04 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex14.exprod.uio.no (2001:700:100:120::76) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Feb 2015 10:18:02 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.1044.021; Wed, 25 Feb 2015 10:18:02 +0100 From: Michael Welzl To: Alex Elsayed Thread-Topic: [Bloat] RED against bufferbloat Thread-Index: AQHQUNv0sUKvBGCaSEK1SlX4B/tmiw== Date: Wed, 25 Feb 2015 09:18:02 +0000 Message-ID: References: <201502250806.t1P86o5N011632@bagheera.jungle.bt.co.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.240.169.59] Content-Type: multipart/alternative; boundary="_000_FC82EEB05E7E473FB9B32BFEC06C7689ifiuiono_" MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 25954 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1F667BB08457EB4D5E321D1BAF804DCEC21867B4 X-UiO-SPAM-Test: remote_host: 129.240.120.76 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 85 total 600970 max/h 441 blacklist 0 greylist 0 ratelimit 0 Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] RED against bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 09:18:37 -0000 --_000_FC82EEB05E7E473FB9B32BFEC06C7689ifiuiono_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two points, below... On 25 Feb 2015, at 09:42, Alex Elsayed > wrote: Bob Briscoe wrote: Sahil, At 06:46 25/02/2015, Mikael Abrahamsson wrote: On Tue, 24 Feb 2015, sahil grover wrote: (i) First of all,i want to know whether RED was implemented or not? if not then what were the reasons(major) ? RED has been available on most platforms, but it was generally not turned on. It also needs configuration from an operator, and it's hard to know how to configure. About a decade ago my company (BT) widely deployed RED in the upstream 'head-end' of our global MPLS network, i.e. the likely bottleneck in the customer edge router where the customer's LAN traffic enters their access link. We deployed it as WRED, i.e. different configurations of RED across the various diffserv classes, in order to minimise queuing latency in all the classes, including the lowest priority class. A configuration calculator was developed to help the engineers during set up. We still use this setup successfuly today, including for all our particularly latency sensitive customers in the finance sector. We did not deploy RED on our broadband platform (ie public Internet), altho in retrospect we should have done, because any AQM is much better than none. We're fixing that now. (ii)Second, as we all know RED controls the average queue size from growing. So it also controls delay in a way or we can say is a solution to bufferbloat problem. Then why it was not considered. It was designed to fix "bufferbloat" long before the bufferbloat word was even invented. It's just that in practice, it doesn't work very well. RED is configured with a drop probability slope at certain buffer depths, and that's it. It doesn't react or change depending on conditions. You have to guess at configure-time. What we need are mechanisms that work better in real life and that are adaptive. If you were prepared to read a paper, I would have suggested: "The New AQM Kids on the Block: An Experimental Evaluation of CoDel and PIE" This compares CoDel and PIE against Adaptive RED, which was a variant of RED proposed by Sally Floyd & co-authors in 2001 and available since Linux kernel version 3.3. ARED addressed the configuration sensitivity problem of RED by adapting the parameters to link rate and load conditions. The paper convinced me that ARED is good enough (in the paper's simulations it was often better than PIE or CoDel), at least for links with fixed rate (or only occasionally varying rate like DSL).* This is important for us because it means we can consider deploying AQM by adding soft controls on top of the RED implementations we already have in existing equipment. This could reduce deployment completion time from decades to a few months. * I'm not sure ARED would be able to cope with the rapidly changing rate of a wireless link tho. One thing that was brought up on the CoDel list (which Sahil's original question was cross-posted to) by Dave Taht is that much of this testing utterly fails to account for two crucial factors: 1.) Asymmetric paths. When the uplink is considerably smaller than the downlink, he's seen significant behavioral differences - and that's _exactly_ the case of DSL. 2.) Elephants, mice and ants - response of mixed (and latency-sensitive) traffic under load. The RRUL (Realtime Response Under Load) toolkit he created is explicitly designed to test this case... which is a close match to common use cases like watching a Youtube video, but still needing things like DNS to be responsive. Or the bursty traffic of web browsing while a VoIP call is occurring. The former is completely ignored by the presentation you linked to, Why exactly did you think we should have looked at asymmetric paths? To stu= dy what? ( I'm not debating that asymmetric paths play out different in behavior. I'= m just saying that one needs to be clear about what exactly is being invest= igated, and why.) and the latter is a one-line mention under "future work": "More realistic traffic types (here, only bulk TCP traffic) including bursty traffic" Considering those, that slide deck convinces me of very, very little indeed= . - it's not just a slide deck, it's a paper, in case you're interested. The = longer version is freely available: https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.= pdf?sequence=3D5 Why no other traffic types? Because we felt that looking at just bulk TCP i= s enough to make the key point that we wanted to get across: maybe it's wor= th taking a look at the vast amount of work that exists on AQMs, as even a = stone old mechanism like ARED does not seem to generally be significantly w= orse than CoDel and PIE. We didn't really want to sell ARED as it is as a much better solution under= all conditions and say that it should now be used instead of CoDel and PIE= (though we do conclude that it creating an ARED++ type mechanism seems wor= th considering). To make that point, I'd agree that one would have to see o= ther traffic types too. A paper saying "We propose ARED++ as a replacement = for CoDel or PIE" should have that. My point is: when developing something new, compare against the state of th= e art. RED is *not* the state of the art, it's very old. I have seen argume= nts like needing parameterless operation because that was the failure of RE= D. Well, Sally Floyd addressed that with ARED ages ago. Most papers cited i= n this survey: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6329367 begin with "RED didn't work because parameters had to be tuned. We propose = a mechanism that doesn't require such tuning..." What I've seen so far: - CoDel compared with RED and BLUE - PIE compared with CoDel - ARED compared with CoDel and PIE ... it would seem reasonable to take one of the many, many mechanisms that = exist - one that was already shown to be better than RED and many others - = , make it use delay as input, and test CoDel and PIE against that. Then I'd= say we have a comparison against the state of the art. Now we don't really= have that, there's a gap here. Cheers, Michael --_000_FC82EEB05E7E473FB9B32BFEC06C7689ifiuiono_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Two points,

below...

On 25 Feb 2015, at 09:42, Alex Elsayed <eternaleye@gmail.com> wrote:
Bob Briscoe wrote:

Sahil,

At 06:46 25/02/2015, Mikael Abrahamsson wrote:
On Tue, 24 Feb 2015, sahil grover wrot= e:

(i) First of all,i want to know whethe= r RED was implemented or not?
if not then what were the reasons(major) ?

RED has been available on most platforms, but it was generally not
turned on. It also needs configuration from an operator, and it's
hard to know how to configure.

About a decade ago my company (BT) widely deployed RED in the
upstream 'head-end' of our global MPLS network, i.e. the likely
bottleneck in the customer edge router where the customer's LAN
traffic enters their access link. We deployed it as WRED, i.e.
different configurations of RED across the various diffserv classes,
in order to minimise queuing latency in all the classes, including
the lowest priority class. A configuration calculator was developed
to help the engineers during set up. We still use this setup
successfuly today, including for all our particularly latency
sensitive customers in the finance sector.

We did not deploy RED on our broadband platform (ie public Internet),
altho in retrospect we should have done, because any AQM is much
better than none. We're fixing that now.

(ii)Second, as we all know RED control= s the  average queue size from
growing.
So it also controls delay in a way or  we can say  is a solution = to
bufferbloat problem. Then why it was not considered.

It was designed to fix "bufferbloat" long before the bufferbloat<= br class=3D""> word was even invented. It's just that in practice, it doesn't work
very well. RED is configured with a drop probability slope at
certain buffer depths, and that's it. It doesn't react or change
depending on conditions. You have to guess at configure-time.

What we need are mechanisms that work better in real life and that
are adaptive.

If you were prepared to read a paper, I would have suggested:
"The New AQM Kids on the Block: An Experimental Evaluation of CoDel an= d
PIE" <http://infocom2014.ieee-infocom.org/GI14-slides/GI1= 4-s2-3.pdf>

This compares CoDel and PIE against Adaptive RED, which was a variant
of RED proposed by Sally Floyd & co-authors in 2001 and available
since Linux kernel version 3.3. ARED addressed the configuration
sensitivity problem of RED by adapting the parameters to link rate
and load conditions.

The paper convinced me that ARED is good enough (in the paper's
simulations it was often better than PIE or CoDel), at least for
links with fixed rate (or only occasionally varying rate like DSL).*
This is important for us because it means we can consider deploying
AQM by adding soft controls on top of the RED implementations we
already have in existing equipment. This could reduce deployment
completion time from decades to a few months.

* I'm not sure ARED would be able to cope with the rapidly changing
rate of a wireless link tho.

One thing that was brought up on the CoDel list (which Sahil's original 
question was cross-posted to) by Dave Taht is that much of this testing 
utterly fails to account for two crucial factors:

1.) Asymmetric paths. When the uplink is considerably smaller than the 
downlink, he's seen significant behavioral differences - and that's 
_exactly_ the case of DSL.

2.) Elephants, mice and ants - response of mixed (and latency-sensitive) 
traffic under load. The RRUL (Realtime Response Under Load) toolkit he 
created is explicitly designed to test this case... which is a close match 
to common use cases like watching a Youtube video, but still needing things 
like DNS to be responsive. Or the bursty traffic of web browsing while a 
VoIP call is occurring.

The former is completely ignored by the presentation you linked to,

Why exactly did you think we should have looked at asymmetric paths? T= o study what?
( I'm not debating that asymmetric paths play out different in behavio= r. I'm just saying that one needs to be clear about what exactly is being i= nvestigated, and why.)


and the 
latter is a one-line mention under "future work":

"More realistic traffic types (here, only bulk TCP traffic) including
bursty traffic"

Considering those, that slide deck convinces me of very, very little indeed.

- it's not just a slide deck, it's a paper, in case you're interested.= The longer version is freely available:

Why no other traffic types? Because we felt that looking at just bulk = TCP is enough to make the key point that we wanted to get across: maybe it'= s worth taking a look at the vast amount of work that exists on AQMs, as ev= en a stone old mechanism like ARED does not seem to generally be significantly worse than CoDel and PIE.

We didn't really want to sell ARED as it is as a much better solution = under all conditions and say that it should now be used instead of CoDel an= d PIE (though we do conclude that it creating an ARED++ type mechan= ism seems worth considering). To make that point, I'd agree that one would have to see other traffic types too. A pap= er saying "We propose ARED++ as a replacement for CoDel or PIE= " should have that.

My point is: when developing something new, compare against the state = of the art. RED is *not* the state of the art, it's very old. I have seen a= rguments like needing parameterless operation because that was the failure = of RED. Well, Sally Floyd addressed that with ARED ages ago. Most papers cited in this survey:
begin with "RED didn't work because parameters had to be tuned. W= e propose a mechanism that doesn't require such tuning..."

What I've seen so far:
- CoDel compared with RED and BLUE
- PIE compared with CoDel
- ARED compared with CoDel and PIE

... it would seem reasonable to take one of the many, many mechanisms = that exist - one that was already shown to be better than RED and many othe= rs - , make it use delay as input, and test CoDel and PIE against that. The= n I'd say we have a comparison against the state of the art. Now we don't really have that, there's a gap here.

Cheers,
Michael

--_000_FC82EEB05E7E473FB9B32BFEC06C7689ifiuiono_--