Re: [aqm] Gaming ECN

David Lang <david@lang.hm> Sat, 21 March 2015 22:47 UTC

Return-Path: <david@lang.hm>
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 047A41A902B for <aqm@ietfa.amsl.com>; Sat, 21 Mar 2015 15:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 x_qiOk4rDkVq for <aqm@ietfa.amsl.com>; Sat, 21 Mar 2015 15:47:19 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466A1A889D for <aqm@ietf.org>; Sat, 21 Mar 2015 15:47:19 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2LMl8xh022847; Sat, 21 Mar 2015 14:47:08 -0800
Date: Sat, 21 Mar 2015 15:47:08 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: John Leslie <john@jlc.net>
In-Reply-To: <20150321012329.GU39886@verdi>
Message-ID: <alpine.DEB.2.02.1503211539090.22474@nftneq.ynat.uz>
References: <20150305121923.30314.56076.idtracker@ietfa.amsl.com> <alpine.DEB.2.02.1503201704130.22474@nftneq.ynat.uz> <20150321012329.GU39886@verdi>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/ybqaxc1_PBAiH39Jn3qv58p-H98>
Cc: aqm@ietf.org
Subject: Re: [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 22:47:21 -0000

On Fri, 20 Mar 2015, John Leslie wrote:

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

is it? or is it that in order to keep the link from being congeted, flows with 
ECN marked (but not honored) will consistantly get more packets through than 
ones wihtout ECN?

If it' just an occasional packet, it's not a big deal, but if the non-ECN flows 
get slowed more because the ECN-marked flows are getting more packet through, 
that's a priority difference, not just an occasional packet.

I wrote this based on the responses of "how could anyone game ECN" where people 
seemed to be thinking that there is no way to gain an advantage from claiming to 
do ECN but then ignoring the congestion signals.

It may be that nobody ever abuses ECN this way, but when introducing something 
new we need to look at ways that it could be abused and what the effects of 
someone trying to abuse it would be.

David Lang