Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - comments still welcome
gorry@erg.abdn.ac.uk Thu, 19 March 2015 07:55 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 CACB41A1B57 for <aqm@ietfa.amsl.com>; Thu, 19 Mar 2015 00:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eFHL4SMBwP3 for <aqm@ietfa.amsl.com>; Thu, 19 Mar 2015 00:55:02 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34A1A001A for <aqm@ietf.org>; Thu, 19 Mar 2015 00:55:02 -0700 (PDT)
Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 28AD41B004B1; Thu, 19 Mar 2015 07:55:17 +0000 (GMT)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 19 Mar 2015 07:54:32 -0000
Message-ID: <1ae61e484a61838497910f994bea75d8.squirrel@erg.abdn.ac.uk>
In-Reply-To: <20150319013909.GR39886@verdi>
References: <a4dc09801ccd09db5350c2eb8a31f216.squirrel@erg.abdn.ac.uk> <CAA93jw74Vr3bhzJcm7WHD2DSFPiMCqQoP5Eimr2due4GJUNPdQ@mail.gmail.com> <20150319013909.GR39886@verdi>
Date: Thu, 19 Mar 2015 07:54:32 -0000
From: gorry@erg.abdn.ac.uk
To: John Leslie <john@jlc.net>
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: <http://mailarchive.ietf.org/arch/msg/aqm/Fdjb4IsrSfvtsBWLenLKzAZpbOU>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Dave Taht <dave.taht@gmail.com>, "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 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 <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. > 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 RFC5405.bis, >> 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 <john@jlc.net> > Gorry
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… Dave Taht
- [aqm] Updated draft-ietf-aqm-ecn-benefits - comme… gorry
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… John Leslie
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… gorry
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… Dave Taht
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… Michael Welzl
- Re: [aqm] Updated draft-ietf-aqm-ecn-benefits - c… Dave Taht