Re: [aqm] AQM schemes: Queue length vs. delay based

"Rong Pan (ropan)" <ropan@cisco.com> Thu, 14 November 2013 22:32 UTC

Return-Path: <ropan@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903D511E80FE for <aqm@ietfa.amsl.com>; Thu, 14 Nov 2013 14:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.371
X-Spam-Level:
X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c-hyI2ooc5N for <aqm@ietfa.amsl.com>; Thu, 14 Nov 2013 14:32:17 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87911E811B for <aqm@ietf.org>; Thu, 14 Nov 2013 14:32:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18930; q=dns/txt; s=iport; t=1384468337; x=1385677937; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Rz1neHRIWm8CK2Fc1aUcYJYr116VmIB4FsKAYpE5ICw=; b=aEZm2lpQINHJInsyVmmMFl2KA03sO0/GF0JOE3hke/Jccv3GTB4GK0oV RMKPMQoahN2nu5zdkRovPKPRhdJVHDuUDRy65qocuu1iV6JnoKBseilVt ufjQRAUBx/c40jE0gJu+6k/Xe8Xs71jcf4evQWgJNVxYWlug0zXgS/+Bk g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAH1OhVKtJV2c/2dsb2JhbABagkNEgQu/HoEhFnSCJQEBAQMBbAYHBQ0BCBEDAQIoKBEUCQgCBA4Fh28DCQa3CQ2JU4xtgSmBOBEHhDEDliWBa4xUhTiDKIFxOQ
X-IronPort-AV: E=Sophos; i="4.93,702,1378857600"; d="scan'208,217"; a="284989134"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 22:32:16 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAEMWAcW009619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 22:32:16 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.147]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 16:32:10 -0600
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Naeem Khademi <naeem.khademi@gmail.com>
Thread-Topic: [aqm] AQM schemes: Queue length vs. delay based
Thread-Index: AQHO3CzV4Y8AQmoIJE6ksgN55dTkopobOREAgADcp4CAACSPAP//9emAgABSr4CABi75AIAA200AgABagICAAB6IAIAAVMEAgADNWwCAACSHAP//sJoAgACnbQD//4M6gA==
Date: Thu, 14 Nov 2013 22:32:10 +0000
Message-ID: <CEAA8EDD.55A7D%ropan@cisco.com>
In-Reply-To: <CAEjQQ5WW_VfXC_PQ=eaZnxg-9n3BrxLk3zKAX3heWedm_shTqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [128.107.165.143]
Content-Type: multipart/alternative; boundary="_000_CEAA8EDD55A7Dropanciscocom_"
MIME-Version: 1.0
Cc: Michael Welzl <michawe@ifi.uio.no>, "aqm@ietf.org" <aqm@ietf.org>, Preethi Natarajan <preethi.cis@gmail.com>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 22:32:23 -0000


From: Naeem Khademi <naeem.khademi@gmail.com<mailto:naeem.khademi@gmail.com>>
Date: Thursday, November 14, 2013 1:58 PM
To: Cisco Employee <ropan@cisco.com<mailto:ropan@cisco.com>>
Cc: Preethi Natarajan <preethi.cis@gmail.com<mailto:preethi.cis@gmail.com>>, "aqm@ietf.org<mailto:aqm@ietf.org>" <aqm@ietf.org<mailto:aqm@ietf.org>>, Michael Welzl <michawe@ifi.uio.no<mailto:michawe@ifi.uio.no>>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based

Hi Rong

comments follow inline

Thanks
Naeem

On Thu, Nov 14, 2013 at 8:59 PM, Rong Pan (ropan) <ropan@cisco.com<mailto:ropan@cisco.com>> wrote:
Please see inline…

Thanks,

Rong



From: Naeem Khademi <naeem.khademi@gmail.com<mailto:naeem.khademi@gmail.com>>
Date: Thursday, November 14, 2013 8:43 AM
To: Preethi Natarajan <preethi.cis@gmail.com<mailto:preethi.cis@gmail.com>>
Cc: "aqm@ietf.org<mailto:aqm@ietf.org>" <aqm@ietf.org<mailto:aqm@ietf.org>>, Michael Welzl <michawe@ifi.uio.no<mailto:michawe@ifi.uio.no>>

Subject: Re: [aqm] AQM schemes: Queue length vs. delay based


Delay-based ARED behaves similar to tail drop at max threshold.

I think I now understand what you mean by this sentence ;-) and therefore please ignore the paragraph responding to this specific point in the previous email (sorry about that, I got it mixed with max_target). Indeed ARED drops every packet when the average queue length grows beyond th_max as drop probability jumps to 1 (when it's not in gentle mode). For this to happen, the "average queue length" has to grow beyond th_max and depending on how the averaging is done, that can correspond to certain burst allowance at AQM. Moreover, this is done over 500 ms interval which means the average queue length has to stay above th_max for mostly few rounds of RTTs (assuming the typical distribution of RTTs on the Internet to have a mean/average somewhere below that value e.g. 100~200 ms). This allows burst that don't take the average queue size to above th_max over 500 ms period to pass and clear themselves up the queue.

 > This is unacceptable of an AQM even for max thresholds around 50ms.

-----------------------------
>>>>>>>>>>>>>RP: Two issues here, first, averaging has a parameter. How to tune it to avoid tail drop behavior? What would be its relationship to max_th? Do we understand ?  Second, one single tcp's behavior is very bursty, if 500ms burst allowance is effective in ARED, how come is it not reflected in your throughput chart? The one single tcp throughput is very low for low latency numbers, which is a clear indication of not enough buffering.
------------------------------------


NAEEMK: As stated before, we're not advocating using ARED whatsoever. Therefore trying to fix/address ARED's inherent issues that have been stated on this thread repeatedly would not be an option nor it enhances the argument to support PIE or CoDel for deployment. So, I'm not going to speculate on how one can possibly fix ARED thresholds and its burst allowance. On the other hand, based on the presented experimental results, we would alternatively like to see why CoDel and PIE performed worse that ARED (designed in 2001) while they were expected to achieve latencies far better than *RED.




RP: If low latencies are achieved at the cost of losing quite a bit of throughput, it is a no-starter for AQM design.



Whether this is a good thing or bad thing is a subjective matter in my opinion, as most AQMs at some point will drop every packet whether it be the maximum queue length or at some thresholds.

----------------------------
>>>>>>>>>>>>RP: I don’t think so. Neither PIE nor Codel has drop-all threshold as AQM part of it. Tail drop exists, but it is not part of AQM. Putting the latency-based  ARED aside, ARED in this current form has the issues that we mentioned in the previous emails. It needs significant and careful redesign.

NAEEMK: The same response as above.

---------------------------

There is also a comment about "Throwing away all the knowledge and improvement gained from RED-like AQMs, CHoKe, etc and coming up with brand-new AQMs …".

------------------------------------------
>>>>>>>>>>RP: After I worked on CHOKe (now in Linux Kernel)  in 2000 as part of my Ph.D. thesis at Stanford, I have worked on AFD (implemented in many Cisco flagship products), QCN (now IEEEE standard for data center ethernet, 802.1Qau), all of which are AQM schemes. I also helped writing guidelines in tuning WRED at Cisco. New thinkings were brought into PIE after I learned precious lessons (both good and bad) from all of them. Discarding them as "coming up with brand-new AQMs" is ignorant.

NAEEMK: agreed! and we are on same side :-) though it will be nice to see the connection points between above AQMs and PIE and lessons learned being somehow documented.

>>>>>>RP: starting reading some of the papers about those designs, especially PIE on HPSR2013, would be a good start….


Regards,

Rong



Regards,

Rong
--------------------------------


Cheers,
Naeem

>>>>>>>>>>>>RP: