Re: [aqm] Immediate ECN: Autotuning AQM for RTT

"Rong Pan (ropan)" <ropan@cisco.com> Sat, 09 November 2013 07:27 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 9B87A21E80F5; Fri, 8 Nov 2013 23:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.485
X-Spam-Level:
X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, 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 XQ+O8WZ1c+pT; Fri, 8 Nov 2013 23:26:57 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 398F221E80F7; Fri, 8 Nov 2013 23:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2169; q=dns/txt; s=iport; t=1383982004; x=1385191604; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/vpEnBrsNnzpJqprwmMdgr2Q7HT/AEkMVf9UhLZlggc=; b=CFfy2kNfHWh4G64KGlcSkZBHQyeBhNW5KnwmxTvYwt0wnHHQxGyrb5yn U94fzZDkRHlZJCkO0jaqrHJ2p9yNfWkpQhD1YolBCtV0ZplPhlHdhZ8C0 1WFfIesQvrlMDJ6pdN8fJInjPlLxd1mcge4bd70fHX1KGaM74NkdB+KRi g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFABjjfVKtJXHB/2dsb2JhbABZgwc4U75QSoEqFnSCJwECAgEBATc0HQEINjcLJQIEARKIAQ29B49uhDADmA+BL5BbgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,666,1378857600"; d="scan'208";a="282819352"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2013 07:26:40 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA97QegQ027898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Nov 2013 07:26:40 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.147]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 9 Nov 2013 01:26:40 -0600
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Bob Briscoe <bob.briscoe@bt.com>, tsv-area IETF list <tsv-area@ietf.org>, AQM IETF list <aqm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [aqm] Immediate ECN: Autotuning AQM for RTT
Thread-Index: AQHO2/SBttchdmU52kqbSkB491ElhpocT9oA
Date: Sat, 09 Nov 2013 07:26:39 +0000
Message-ID: <CEA32194.550FE%ropan@cisco.com>
In-Reply-To: <201311072003.rA7K38dj008566@bagheera.jungle.bt.co.uk>
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: [10.21.114.54]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <33D401EC59EEEF4D98A6A1BA5C6A87CD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [aqm] Immediate ECN: Autotuning AQM for RTT
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: Sat, 09 Nov 2013 07:27:01 -0000

I just got a better understanding of Bob's proposal. Great direction
indeed! I fully agreed that doing the smoothing at the end hosts and
simple network congestion signals is the best way to achieve low averaging
latency. 

We do need these three working groups working together to get this done.
But since folks usually attend all these three meetings at IETF, I am
hopeful that IETF can make it happen with all our efforts together here.

Bob, 

a technical question. If we do no averaging for ECN, and hosts use the
tradition ECN-capable TCP, I am afraid its window might get cut too much
to achieve any reasonable throughput. Any thought on how to handle that?
Or maybe you already covered in your slides and I missed it?

Thanks,

Rong



On 11/7/13 12:03 PM, "Bob Briscoe" <bob.briscoe@bt.com> wrote:

>Folks,
>
>"Immediate ECN" slides:
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pptx>
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pdf>
>
>PS. This talk fell off the end of the TSVAREA agenda. It's mostly
>relevant to AQM, but I didn't originally bring it to AQM, because it
>affects 3 wgs: tsvwg, aqm & tcpm.
>
>In the AQM wg, there was dismay about CableLabs not including
>anything about ECN in DOCSIS3.1. This talk is about AQM dynamics; and
>how ECN can take out the 100ms of delay that CoDel and PIE introduce
>- it's essentially about auto-tuning for RTT.
>
>It gives an interim recommendation for hardware designers that there
>should be a second instance of the AQM algo for ECN packets so that
>it can be configured with different parameters (think of WRED instead of
>RED).
>
>Specifically, for ECN packets:
>interval = 0 (for CoDel)
>max_burst = 0 (for PIE)
>
>
>Bob
>
>PS. We have a paper under submission, which we can supply on request.
>We plan to document this in the IETF too.
>
>
>
>
>________________________________________________________________
>Bob Briscoe,                                                  BT
>
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm