Re: [aqm] ECN: was Control Theoretic Analyses of PI(E)

KK <kk@cs.ucr.edu> Tue, 27 January 2015 10:51 UTC

Return-Path: <kk@cs.ucr.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28BB1A8748 for <aqm@ietfa.amsl.com>; Tue, 27 Jan 2015 02:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2CwCmuDMKrh for <aqm@ietfa.amsl.com>; Tue, 27 Jan 2015 02:51:31 -0800 (PST)
Received: from send.cs.ucr.edu (send.cs.ucr.edu [169.235.30.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A011A701E for <aqm@ietf.org>; Tue, 27 Jan 2015 02:51:31 -0800 (PST)
Received: from [192.168.1.73] (108-244-26-233.lightspeed.irvnca.sbcglobal.net [108.244.26.233]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by send.cs.ucr.edu (Postfix) with ESMTP id DFB9B16D83FD; Tue, 27 Jan 2015 02:51:27 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Tue, 27 Jan 2015 02:51:25 -0800
From: KK <kk@cs.ucr.edu>
To: aqm@ietf.org, john@jlc.net, Vishal Misra <misra@cs.columbia.edu>
Message-ID: <D0ECAA28.2186%kk@cs.ucr.edu>
Thread-Topic: ECN: was Control Theoretic Analyses of PI(E)
References: <20150126171439.GC49615@verdi> <AB90C304-9AFB-4D51-B937-EE38153983CF@cs.columbia.edu>
In-Reply-To: <AB90C304-9AFB-4D51-B937-EE38153983CF@cs.columbia.edu>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/hhhyGBirAMPUDBtnGZ-c0HOcIi8>
X-Mailman-Approved-At: Tue, 27 Jan 2015 04:04:52 -0800
Subject: Re: [aqm] ECN: was Control Theoretic Analyses of PI(E)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 27 Jan 2015 10:52:56 -0000

I am not a participant on this list (I should join), but was forwarded
this particular email - which was certainly of interest to me.

As described in the ECN RFC, we had constructed ECN to explicitly take
advantage of AQM mechanisms, and would indeed provide the benefits of AQM
-- reduced packet latency and loss. One of the implicit benefits of AQM is
the decoupling of loss from being the key means for congestion management,
and ECN is the means for AQM to provide the necessary indication needed
for the feedback control loop to work.

On the comment made below - when we constructed ECN, we were particularly
careful to make the scheme robust to loss of the packets carrying the
indication (whether in the packet or the Acks). The CWR provides a means
for the source taking the action (and thus completing the feedback control
loop) to provide an indication that the ECN notification has been acted
upon. We fully recognized that buffer overflows can cause ECN-marked
packets (and/or Acks) to be lost. Thus, there is no reason to set aside
ECN-marked packets for being forwarded when the buffer overflows.
Obviously, we would like this to not happen frequently (and if all the
sources were cooperating (obviously only in an ideal world) and the
AQM/ECN mechanism was working, it wouldn¹t happen frequently), but the way
ECN is constructed, it is robust to such occurrences.
Thanks,
-- 
K. K. Ramakrishnan
Professor
Dept. of Computer Science and Engineering
University of California, Riverside
Rm. 332, Winston Chung Hall
Tel: (951) 827-2480


>
>> Begin forwarded message:
>> 
>> Date: January 26, 2015 at 12:14:39 PM EST
>> From: John Leslie <john@jlc.net>
>> To: Vishal Misra <misra@cs.columbia.edu>
>> Cc: aqm@ietf.org
>> Subject: ECN: was Control Theoretic Analyses of PI(E)
>> 
>> Vishal Misra <misra@cs.columbia.edu> wrote:
>>> <snip>
>>> 
>>><http://dna-pubs.cs.columbia.edu/citation/paperfile/23/MisraInfocom01-AQ
>>>M-Controller.pdf>
>>> ...
>>> One thing to note though that hasn't changed all these years is if you
>>> look at Section VII.A of our PI paper linked above, the full benefits
>>> of AQM are realized in conjunction with ECN. On a bottlenecked link,
>>> if you reduce delay (by controlling it via a mechanims like PI(E) or
>>> CoDel), unless you have ECN implemented you will end up increasing
>>> loss rates which may not be a good thing.
>> 
>>   I wish we'd discuss ECN more here, and state some benefit of its use;
>> perhaps even discuss how to route-around its misuse along the path.
>> 
>>   We should (IMHO) note that it's many years since its use in congestion
>> control could possibly be "the same as packet drop" -- and by the nature
>> of AQM, packets need to be ECN-marked before anything must be dropped
>> due to buffer overflow.
>> 
>>   Obviously (IMHO), an ECN-capable packet which encounters buffer
>> overflow needs to be dropped: not held until it can be ECN-marked and
>> forwarded.
>> 
>> --
>> John Leslie <john@jlc.net>
>
>