Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - comments still welcome

John Leslie <john@jlc.net> Thu, 19 March 2015 01:39 UTC

Return-Path: <john@jlc.net>
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 013391A6FF6 for <aqm@ietfa.amsl.com>; Wed, 18 Mar 2015 18:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 64boWPhHetMn for <aqm@ietfa.amsl.com>; Wed, 18 Mar 2015 18:39:23 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAF51A1BBC for <aqm@ietf.org>; Wed, 18 Mar 2015 18:39:23 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 8357CC94A9; Wed, 18 Mar 2015 21:39:09 -0400 (EDT)
Date: Wed, 18 Mar 2015 21:39:09 -0400
From: John Leslie <john@jlc.net>
To: Dave Taht <dave.taht@gmail.com>
Message-ID: <20150319013909.GR39886@verdi>
References: <a4dc09801ccd09db5350c2eb8a31f216.squirrel@erg.abdn.ac.uk> <CAA93jw74Vr3bhzJcm7WHD2DSFPiMCqQoP5Eimr2due4GJUNPdQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAA93jw74Vr3bhzJcm7WHD2DSFPiMCqQoP5Eimr2due4GJUNPdQ@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/_ODVqtJwkS-tvIbKeTlhcQPfq9Y>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - comments still welcome
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: Thu, 19 Mar 2015 01:39:25 -0000

Dave Taht <dave.taht@gmail.com> 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. 

> 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.

>     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 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.

--
John Leslie <john@jlc.net>