Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-01.txt

David Lang <david@lang.hm> Sat, 21 March 2015 00:11 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 BF8AA1ACED9; Fri, 20 Mar 2015 17:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xj9xBEnFud6C; Fri, 20 Mar 2015 17:11:53 -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 E99611ACED8; Fri, 20 Mar 2015 17:11:52 -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 t2L0BoBl018930; Fri, 20 Mar 2015 16:11:51 -0800
Date: Fri, 20 Mar 2015 17:11:50 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: internet-drafts@ietf.org
In-Reply-To: <20150305121923.30314.56076.idtracker@ietfa.amsl.com>
Message-ID: <alpine.DEB.2.02.1503201704130.22474@nftneq.ynat.uz>
References: <20150305121923.30314.56076.idtracker@ietfa.amsl.com>
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/iwpI440Qy3IFWxmC7SeJz5KJkfE>
Cc: aqm@ietf.org, i-d-announce@ietf.org
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-01.txt
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 00:11:54 -0000

re: gaming ECN

apologies for not replying to the right message, I deleted them earlier before 
deciding to respond.

Programmers are going to game ECN to their advantage (or at least to their 
perceived advantage)

There are three ways to mark flows as congested

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

2. at the level that you drop packets for non-ECN flows, you mark and allow ECN 
flows to continue

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


If you do #2, then flows with ECN effectively get priority over flows without 
ECN (as you don't actually force them to back off, you are just asking them to)

   Programmers will mark everything with ECN and not back off

If you do #3, then flows with proper ECN yield to flows without ECN, giving 
effective priority to flow without ECN

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


If everyone uses ENC and backs off properly, then #3 is better as you don't have 
the delays caused by re-sending packet. But in a mixed environment, ECN is going 
to be gamed one way or the other.

David Lang