Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - comments still welcome Thu, 19 March 2015 07:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CACB41A1B57 for <>; Thu, 19 Mar 2015 00:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6eFHL4SMBwP3 for <>; Thu, 19 Mar 2015 00:55:02 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id 5E34A1A001A for <>; Thu, 19 Mar 2015 00:55:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPA id 28AD41B004B1; Thu, 19 Mar 2015 07:55:17 +0000 (GMT)
Received: from (SquirrelMail authenticated user gorry) by with HTTP; Thu, 19 Mar 2015 07:54:32 -0000
Message-ID: <>
In-Reply-To: <20150319013909.GR39886@verdi>
References: <> <> <20150319013909.GR39886@verdi>
Date: Thu, 19 Mar 2015 07:54:32 -0000
To: "John Leslie" <>
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <>
Cc: Gorry Fairhurst <>, Dave Taht <>, "" <>
Subject: Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - comments still welcome
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Mar 2015 07:55:05 -0000

Thanks Dave for reading this ID and providing your comments. It's really
good to explore what may be missing.

> Dave Taht <> wrote:
>> section 6 addition. (could use more verbiage)
>> 6.3 "An AQM that is ECN aware MUST have overload protection.
>    I fear I cannot discern what you mean this to say. :^(
>> It is trivial for a malbehaved application/worm/bot to mark all
>> its packets with ECN and thus gain priority over other traffic
>> not ecn marked.
>    This somewhat-paranoid claim rests on several assumptions that I
> hope we will recommend against.
> - the most obvious is an assumption that a tail-drop node will mark
>   _instead_ of dropping ECN-capable packets. This is not actually
>   possible, and I hope we will strongly deprecate it. Tail-drop should
>   drop packets regardless of ECN bits.
> - there is also an assumption that an ECN-capable transport can mark
>   its packets as ECN-capable and then never reduce its sending rate.
>   I suppose it could; but not-ECN-capable transports can also never
>   reduce the sending rate. :^( And the not-ECN-capable transports
>   could accomplish the same reduction in "lost" packets by FEC.
>    I believe we are going to "suggest" a lower marking threshhold for
> ECN-capable packets than the dropping threshhold for not-ECN-capable
> packets at AQM-capable nodes. This should reduce the paranoia level,
> I hope, since the ECN-capable flows will get congestion signals when
> not-ECN-capable packets are _not_ being dropped.
>    We should concentrate our efforts on providing useful signals:
> that some transports might make poor use of these signals is beyond
> our scope.
I understand that router overload needs to be considered in the design of
an  AQM algorithm, but I inclined to think there is not much say to
application designers, and that this need may have been said said in the
AQM Recommendations document. Agreeing with John, I don't see this as the
place to start putting detail on how routers implement AQM.

>> 6.4 Enabling ECN at the application layer requires access to the IP
>>     header fields, which are usually abstracted out completely at the
>>     tcp layer, and hard to access from udp with multiple non-portable
>>     methods to do so.
>    Yes, there are TCP stacks which are ECN-unfriendly; but there are
> enough _today_ which are friendly to ECN.
I also agree with what you say - although, again I'm not sure we need to
add this here, I think the design of transports is really the topic of

>>     ECN over UDP in new applications such as webrtc and Quic has
>>     great potential for many other applications, however the same
>>     care of design that went into ECN on TCP needs to go into
>>     future UDP based protocols.
>    I wouldn't disagree; but those issues are essentially-solved
> problems today.
>> Some other section that may end up here?
>> ECN marking other sorts of flows (example routing packets) that have a
>> higher priority than other flows on link-local packets may be of benefit
>> with wider availability of aqm technologies that are ecn aware...
 I'm not sure I understand what you are suggesting with respect to ECN.

>    I suppose there might be _some_ use for ECN on routing packets; but
> I doubt this is desirable today. ECN is not-at-all about getting a
> higher priority -- it's about getting congestion signals without
> packet loss.
I think the IETF would normally recommend diffserv priority marking for
network control traffic.

> --
> John Leslie <>