Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02

"De Schepper, Koen (Koen)" <koen.de_schepper@alcatel-lucent.com> Fri, 27 March 2015 15:40 UTC

Return-Path: <koen.de_schepper@alcatel-lucent.com>
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 DF91C1A0231 for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 08:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iYO7ii0BBd8z for <aqm@ietfa.amsl.com>; Fri, 27 Mar 2015 08:40:22 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BA61A0123 for <aqm@ietf.org>; Fri, 27 Mar 2015 08:40:22 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 766E5F6132E7F; Fri, 27 Mar 2015 15:40:18 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2RFeL2d009499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 16:40:21 +0100
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 16:40:21 +0100
From: "De Schepper, Koen (Koen)" <koen.de_schepper@alcatel-lucent.com>
To: Michael Welzl <michawe@ifi.uio.no>, "davecb@spamcop.net" <davecb@spamcop.net>
Thread-Topic: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02
Thread-Index: AQHQZydMeVNCFQUvlUCBL2CLzbbo950tfbgAgAGsMYCAAH0FgIAA0X+w
Date: Fri, 27 Mar 2015 15:40:20 +0000
Message-ID: <BF6B00CC65FD2D45A326E74492B2C19FB75BAFA0@FR711WXCHMBA05.zeu.alcatel-lucent.com>
References: <23AFEFE3-4D93-4DD9-A22B-952C63DB9FE3@cisco.com> <BF6B00CC65FD2D45A326E74492B2C19FB75BAA82@FR711WXCHMBA05.zeu.alcatel-lucent.com> <72EE366B-05E6-454C-9E53-5054E6F9E3E3@ifi.uio.no> <55146DB9.7050501@rogers.com> <08C34E4A-DFB7-4816-92AE-2ED161799488@ifi.uio.no>
In-Reply-To: <08C34E4A-DFB7-4816-92AE-2ED161799488@ifi.uio.no>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/PbdGWnzD-wT_Hz0I2LrUjJ0lxCw>
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02
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: Fri, 27 Mar 2015 15:40:27 -0000

Hi all,

Agreed that there implementations should not be described. Also agree that we should describe all the benefits of using ECN, so I propose to reformulate something as follows:

ECN allows to introduce and deploy state of the art ECN based congestion controllers, 
and to guarantee throughput fairness by applying in the network an appropriate 
relation between marking and dropping.

The extra benefits of supporting these improved ECN based congestion controllers are:

- low latency AND high throughput (compared to low latency OR high throughput for drop 
based congestion controllers)
- reduced variability in flow fairness between competing flows because of the high 
marking rate
- scalability to higher throughputs because the marking rate is independent from the 
throughput

Disadvantage is that congestion controllers that are optimized for drop signals cannot 
use ECN without experiencing high throughput unfairness.

Regards,
Koen.

-----Original Message-----
From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Michael Welzl
Sent: vrijdag 27 maart 2015 5:04
To: davecb@spamcop.net
Cc: aqm@ietf.org
Subject: Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02


> On 26. mar. 2015, at 15.36, David Collier-Brown <davec-b@rogers.com> wrote:
> 
> On 03/25/2015 03:03 PM, Michael Welzl wrote:
>> Hi,
>> 
>> Below:
>> 
>> 
>>> On 25. mar. 2015, at 13.12, De Schepper, Koen (Koen) 
>>> <koen.de_schepper@alcatel-lucent.com>
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Related to DCTCP and different (more) marking ECN than dropping (let's call it ECN++ in this mail), the talk I gave in iccrg (Data Center to the Home) shows that it is possible to have fairness between ECN++ flows (DCTCP, Relentless TCP, Scalable TCP, ...) and drop based Reno/Cubic flows.
>>> 
>>> The ECN++ flows typically respond to marking proportional to 1/p (with p the marking or dropping probability), while the Reno flavors respond proportional to 1/p^0.5 (one over square root of p).
>>> 
>>> This means that the only difference between marking and dropping is that an AQM has to think twice before it drops, and that is what we want, right? We mark fast by comparing our congestion indicator (derived from the queue size or packet sojourn time, or PI controller) with a random generated value. For a drop decision we just can compare the congestion indicator with the maximum of 2 random values (= thinking twice and is resulting in a drop probability which is the square of the marking probability). This will compensate the square root in Reno-like TCPs. If it is a problem to generate 2 random values per packet, you can keep your previous random value, as it is (pseudo) independent of the newly generated.
>>> 
>>> As this is a very simple relation between marking and dropping, AND it gives extra advantages, it is worth considering. The EXTRA advantages are:
>>> - low latency AND high throughput (compared to low latency OR high 
>>> throughput)
>>> - less variability in flow fairness between competing flows (because of the high marking probability, the flows get more signals and will stray of less). If you get one drop every 10 seconds, and you had bad luck that your flow got 2 drops in a row, you have reduced your throughput by 4, compared to the other flow who should have had the second mark, running still at full throughput.
>>> - The marking will scale to higher throughputs, every flow will get the same signal rate independent from the throughput (preferably every millisecond). It is a solution which scales to the future.
>>> 
>>> If we want to promote the use of ECN, let's make sure we get all the benefits, and have a solution that doesn't need to be revised after x years anyway. This is an opportunity to do it better this time, with lots of benefits which might convince people to finally use ECN.
>>> 
>>> I propose to recommend the "think twice" concept, or at least describe its extra benefits in the draft.
>>> 
>> This draft is not specifying a new behavior for ECN, which is what you propose. Thus I think this is out of scope of this document.
>> 
>> 
> 
> I might suggest this is an implementation of a relationship between ECN and drop, based on an observation of how fairness might be achieved.  
> 
> The implementation doesn't belong, unless you have an appendix of interesting implementation concerns.

Yes -


>  The observation that 
> 	* there is a relationship between ECN and drop
> 	* there are fairness problems to consider, and
> 	* there are values of the relationship that minimize or exclude the 
> fairness problem is new, a genuinely good thing, and arguably deserves mention as a benefit.

Every item in your list is so vague that I can't see the value of adding it. I think these things have to be coupled with a specific algorithm (such as the one described above) to make sense - but I think we agree that this document isn't the place for a new algorithm.

Cheers,
Michael

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm