Re: [aqm] adoption call: draft-welzl-ecn-benefits

Michael Welzl <michawe@ifi.uio.no> Mon, 11 August 2014 21:38 UTC

Return-Path: <michawe@ifi.uio.no>
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 206541A01D8 for <aqm@ietfa.amsl.com>; Mon, 11 Aug 2014 14:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 5G6PhpYRdUd7 for <aqm@ietfa.amsl.com>; Mon, 11 Aug 2014 14:38:12 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 8E3261A014D for <aqm@ietf.org>; Mon, 11 Aug 2014 14:38:11 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1XGxI9-0006Yz-4u; Mon, 11 Aug 2014 23:38:09 +0200
Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1XGxI8-0005yB-GK; Mon, 11 Aug 2014 23:38:09 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A90C43A-57AD-4F63-B7B7-6B4405D3D2DD"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <CAA93jw7ufoEdfGexKMwkSOGLj7LMYBq-nGVPGJt+5G+OHx+ayA@mail.gmail.com>
Date: Mon, 11 Aug 2014 23:38:09 +0200
Message-Id: <B64C7136-332D-485C-8D7D-CF92AAC4B247@ifi.uio.no>
References: <53E8D7B0.9040007@mti-systems.com> <CAA93jw7ufoEdfGexKMwkSOGLj7LMYBq-nGVPGJt+5G+OHx+ayA@mail.gmail.com>
To: Dave Taht <dave.taht@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 4 total rcpts 19125 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, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EE4BA5C87796E1D54E75CBB4E773AE492C4BC923
X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 107 max/h 5 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/cUoQnROQgCt3p7yGjS_dQGpprNI
Cc: Wesley Eddy <wes@mti-systems.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] adoption call: draft-welzl-ecn-benefits
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: Mon, 11 Aug 2014 21:38:15 -0000

Hi,

Thanks for your feedback! More below:


On 11. aug. 2014, at 20:19, Dave Taht <dave.taht@gmail.com> wrote:

> On Mon, Aug 11, 2014 at 7:48 AM, Wesley Eddy <wes@mti-systems.com> wrote:
>> This draft has been discussed a bit here and in TSVWG:
>> 
>> http://tools.ietf.org/html/draft-welzl-ecn-benefits-01
>> 
>> As I understand, the IAB has also discussed it a bit, and would
>> be happy if this was something that an IETF working group
>> published.  I believe the TSVWG chairs also discussed this and
>> would be fine if the AQM working group adopted it.
>> 
>> That said, there have only been a small number of mail list
>> comments here about it, and we (unfortunately) didn't devote
>> much of any meeting time to it in Toronto.
>> 
>> So, *please* let us know your thoughts on this in the next few
>> weeks.  I believe we would try to complete it relatively quickly
>> (e.g. 6 months) as an Informational RFC, assuming there is
>> consensus and AD approval to add the milestone.
>> 
>> I personally would like to see some stronger support for it from
>> this working group in order to feel good about adopting it, though
>> I think it is correct and may be "motherhood and apple pie" to
>> many of us.
> 
> I don't share the relentless optimism of this document, and would
> like it - or a competing document - to go into the potential negatives.
> 
> examples of this include the TOS washing problem bob alluded to
> in one of the tsvwg meetings (the monday one),

This is an interesting point. I was somewhat torn about this document myself, in that it recommends to "turn on ECN", but doesn't say how - personally, in fact, I'd not want to recommend using it like it's been used on up to now, but I also have no clear recommendation yet.

Meanwhile, we (authors) have agreed that we'd rather stay away from recommending to "turn on ECN", but rather use the document to recommend to "be compatible" with it - i.e. *not* wash the TOS bits, and if you're a server, correctly reflect the bits.

This makes the TOS washing problem not a negative point of ECN, but the behavior that the document recommends against.


> the impact on
> competing flows,

This gets into the specific congestion control response to ECN, and the rules for ECN-marking. We try to stay away from such specifics in this document because we don't want to recommend one particular behavior here. I'd agree that not going into such specifics is wrong for a document that recommends to "turn on ECN", but we intend to no longer do that.


> the problem of unresponsive agents or other
> misuse,  the deprecation (?) of the nonce mechanism,

Not deprecated (yet?) AFAIK.


> and how to
> properly switch between marking and dropping in an aqm.
> There are also the possibilities in new uses for ecn (for example, in
> the original rmcat nada proposal), in usages on local links in routing
> protocols, and in new protocols such as quic, etc.

Again, specific congestion control reactions.

Cheers,
Michael