[aqm] Gaming ECN

John Leslie <john@jlc.net> Sat, 21 March 2015 01:23 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 072231A1BA5 for <aqm@ietfa.amsl.com>; Fri, 20 Mar 2015 18:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L3wSXBNPgwnn for <aqm@ietfa.amsl.com>; Fri, 20 Mar 2015 18:23:44 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net []) by ietfa.amsl.com (Postfix) with ESMTP id 281F91A1B95 for <aqm@ietf.org>; Fri, 20 Mar 2015 18:23:43 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6F27CC94BD; Fri, 20 Mar 2015 21:23:29 -0400 (EDT)
Date: Fri, 20 Mar 2015 21:23:29 -0400
From: John Leslie <john@jlc.net>
To: David Lang <david@lang.hm>
Message-ID: <20150321012329.GU39886@verdi>
References: <20150305121923.30314.56076.idtracker@ietfa.amsl.com> <alpine.DEB.2.02.1503201704130.22474@nftneq.ynat.uz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1503201704130.22474@nftneq.ynat.uz>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/ajUGXd5sRosqDHvzsVL7Ob_bX98>
Cc: aqm@ietf.org
Subject: [aqm] Gaming ECN
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: Sat, 21 Mar 2015 01:23:46 -0000

David Lang <david@lang.hm> wrote:
> re: gaming ECN
> Programmers are going to game ECN to their advantage (or at least to their 
> perceived advantage)

   Some programmers will, no doubt...

> There are three ways to mark flows as congested

   (Note any real path will likely have a mixture of these...)

> 1. at the same level that you drop packets and then drop the packets at 
>    this level (why bother)

   Many nodes do this today, simply by ignoring ECN-capable marking.

> 2. at the level that you drop packets for non-ECN flows, you mark

   This _is_ the prescribed way to implement ECN today.

>    and allow ECN flows to continue

   Without deep-packet-inspection and saving _considerable_ state,
no node can "allow" or "disallow" a particular flow to continue.

   Thus essentially no nodes try to "disallow" flows -- they merely
provide signals of congestion.

> 3. at a level below the point that you drop packets for all flows, you mark 
>    ECN flows as congested

   This is what we have been talking about -- claiming it could result
in better signals.

> If you do #2, then flows with ECN effectively get priority over flows 
> without ECN

   It's not "priority". It's an occasional packet which gets through
instead of being dropped.

> (as you don't actually force them to back off, you are just asking
> them to)

   We're not even "asking them" -- we're providing a signal.

   We _can't_ force them to back off.

   A not-ECN-capable flow could achieve the same result with Forward-
Error-Correction tactics: include enough redundancy to regenerate
all lost packets, and also decline to back off the sending rate.

> Programmers will mark everything with ECN and not back off

   Perhaps some will.

   Certainly others will use FEC and not back off.

   So what?

> If you do #3, then flows with proper ECN yield to flows without ECN,

   As ECN is defined today, indeed they will.

> giving effective priority to flows without ECN

   We are not (yet) proposing any particular mechanism for ECN-marking
at an earlier congestion status. If we do sometime propose a mechanism,
this will serve as an incentive to upgrade to it.

> Programmers will not use ECN as it puts their traffic at a disadvantage

   Programmers will use ECN when it offers them an advantage.

   In some cases, reducing packet loss _is_ that advantage; and
backing off the sending rate is perfectly acceptable.

   In the future we may define algorithms that encourage stopping the
exponential increase in sending rate without asking for a radical
reduction in sending rate at the first ECN mark. There are types of
traffic which would find that tradeoff _very_ attractive.

   But that's out of scope for us in this document -- just as any
attempt to force flows to back off is out of scope.

> If everyone uses ENC and backs off properly, then #3 is better as you
> don't have the delays caused by re-sending packet.

   Thank you.

> But in a mixed environment, ECN is going to be gamed one way or the other.

   So what?

   (BTW, I'd ask that same "So what?" for any problems of gaming
not-ECN-capable traffic.)

   I would support explaining the problems you see; but I can't see
abandoning the effort because you see problems.

John Leslie <john@jlc.net>