Re: [aqm] ECN use statement

"Fred Baker (fred)" <fred@cisco.com> Fri, 08 November 2013 20:22 UTC

Return-Path: <fred@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9F111E8241 for <aqm@ietfa.amsl.com>; Fri, 8 Nov 2013 12:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.354
X-Spam-Level:
X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM6oK4HxHFtn for <aqm@ietfa.amsl.com>; Fri, 8 Nov 2013 12:22:10 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 062AD11E8224 for <aqm@ietf.org>; Fri, 8 Nov 2013 12:22:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2275; q=dns/txt; s=iport; t=1383942124; x=1385151724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FgrkIP9LJ4J2AYsGVNDuJgrIetmQLH65qBS/5UOgSm0=; b=OfQyuEd4Ke68T0DUXiwTz4Qn+noxiNRutHoL7NsST8W1zNPeFaDy+cjv U5D1B/9pWM+CAuV4QIID1wYa+4rONxxGXaR7NOzl7cee+BgrZvnyMFryd RLc5C1BjIefxSm3yPJr0dqk4k89ypJ4OnHF3QcuJfLcCjGywezFdU949R 0=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAAFHfVKtJXG9/2dsb2JhbABZgweBC78WgTEWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDodtBr02j2cHgyCBEAOQMIEwhi+SC4Mmgio
X-IronPort-AV: E=Sophos; i="4.93,662,1378857600"; d="asc'?scan'208"; a="282592947"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 08 Nov 2013 20:22:03 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA8KM3E9031862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 20:22:03 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 14:22:03 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
Thread-Topic: [aqm] ECN use statement
Thread-Index: AQHO3MAvQS4FJP5dQ02Kex+90ftMtw==
Date: Fri, 08 Nov 2013 20:22:02 +0000
Message-ID: <ECC4EE5E-93F0-447F-94B5-EBFE2FFA2A7C@cisco.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F25E6A876@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25E6A876@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.148.94]
Content-Type: multipart/signed; boundary="Apple-Mail=_8948142A-F9B5-406A-ACA2-C8A3C435DE25"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] ECN use statement
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 20:22:15 -0000

On Nov 5, 2013, at 3:04 PM, "Scheffenegger, Richard" <rs@netapp.com> wrote:

> Hi,
>  
> In today’s discussion it became apparent, that we might need a stronger statement around the expected use of the IP ECN signaling, and encourage future implementers to support this, and also agree around the way how ECN should be used.
>  
> I would like to encourage discussion around that interaction here on list…

Part of the discussion, of course, should be exactly what words we want to say about it. Section 4.2.1 of draft-ietf-awm-recommendations is entirely on ECN, and in part says

   Network devices SHOULD use an AQM algorithm that marks ECN-capable
   traffic when making decisions about the response to congestion.
   Network devices need to implement this method by marking ECN-capable
   traffic or by dropping non-ECN-capable traffic.

Bob's comments this morning in tsvwg (which I wasn't present for but have been appraised of since) were in effect that ECN signals should be far more aggressive than loss signals. While loss is an effective signal, it also has QoE issues as identified in a separate thread, while ECN has no QoE impact. I have two views on that, diametrically opposed:

1) I wish everything would use ECN, so that we could achieve 100% utilization with statistically zero queuing delay and without loss.

2) Would that have the same effect as delay-based TCPs experience with respect to loss-based ones - they back out of the way too early? 

It would be good to get some experience on that.