Re: [aqm] ECT(1)

Jonathan Morton <chromatix99@gmail.com> Fri, 07 August 2015 07:55 UTC

Return-Path: <chromatix99@gmail.com>
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 04DFB1A00EC for <aqm@ietfa.amsl.com>; Fri, 7 Aug 2015 00:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 CYH9P-tZwzCy for <aqm@ietfa.amsl.com>; Fri, 7 Aug 2015 00:55:30 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C781A00E3 for <aqm@ietf.org>; Fri, 7 Aug 2015 00:55:30 -0700 (PDT)
Received: by ykcq64 with SMTP id q64so77984656ykc.2 for <aqm@ietf.org>; Fri, 07 Aug 2015 00:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7AjuhgtnartUYMWOPRzRCVFuyH/A113zqX4o7k7+0Ro=; b=uGCXfd3e1J55cdpPFpiFbYzTWLDV3BJodwXZh6GdkeYAiIaA1Pk1gI2StbR96bmhjR LAYE6qILrxj5klNeOcrpqbnhtDIxNGOnT7zBMME8t59aJ4FwdxWee0zqOgdk6TNk2wNA YSUt1/ilWXkyjMQ7wTE86WpJtbnDBhm8n9XXTroQWi0K0yH+HBY7a2NHOh0haAPAH4jy bXNH1eg8tJo2m1BlLxi88df+RmeCjXq0zcbQoqQnLwmJdlDOnPHed7m58+vKs0M42YeA Kt5/Pg5EvJPbC1SD0vfKzi0PGsn0ZDM4Edzpwq4PusQ27dO6XfEg2ERWgNNXVVpivgGf 7KDg==
MIME-Version: 1.0
X-Received: by 10.129.134.131 with SMTP id w125mr6139072ywf.115.1438934130140; Fri, 07 Aug 2015 00:55:30 -0700 (PDT)
Received: by 10.37.26.9 with HTTP; Fri, 7 Aug 2015 00:55:29 -0700 (PDT)
Received: by 10.37.26.9 with HTTP; Fri, 7 Aug 2015 00:55:29 -0700 (PDT)
In-Reply-To: <CAPRuP3mFDprONVDpuidymTcBqX-9SyoF1FAddisC3Pe43nXAsQ@mail.gmail.com>
References: <ba3b6f6b4d3d453d887c451fbca412fa@hioexcmbx05-prd.hq.netapp.com> <CAA93jw5WrT0Azcew_gic5H-tJtBo62m-f4fBB0=qQp01uf3VuQ@mail.gmail.com> <8a1ed5a975d44a7bad88dc573971ded5@hioexcmbx05-prd.hq.netapp.com> <20150728145036.GK96964@verdi> <55BFF7EC.1010608@bobbriscoe.net> <alpine.DEB.2.02.1508061242450.11810@uplift.swm.pp.se> <CAPRuP3mFDprONVDpuidymTcBqX-9SyoF1FAddisC3Pe43nXAsQ@mail.gmail.com>
Date: Fri, 07 Aug 2015 10:55:29 +0300
Message-ID: <CAJq5cE0TRj=QQD3nbVjDoTBhjecOjjAy7ecKCGbZvB66eXK7_Q@mail.gmail.com>
From: Jonathan Morton <chromatix99@gmail.com>
To: Andrew Mcgregor <andrewmcgr@google.com>
Content-Type: multipart/alternative; boundary="001a114efe80aeae08051cb3f515"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/-iUPSdie_G-mKYMf7Y0cj4YAIAM>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Bob Briscoe <research@bobbriscoe.net>, aqm@ietf.org
Subject: Re: [aqm] ECT(1)
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Aug 2015 07:55:32 -0000

A flow-isolating AQM such as fq_codel would be able to deal with different
flows responding differently to CE.

The problem is that core and semi-core network nodes don't have the
resources to do flow isolation at line rate, or (equivalently) they deal
with too many simultaneous flows to make a meaningful flow isolation scheme
practically implementable.  This, I assume, is where the dual queue
proposal comes in.

Fundamentally, dual queue needs to be able to identify the packets
belonging to each queue.  DSCP is a non-starter because it doesn't, in
practice, survive end to end.  I'm wary of using the ECN field for the same
purpose - it could work, but promotimg CE packets from classic ECN flows
could result in spurious retransmissions due to reordering.  Simply using
the presence of ECN capability is also a bad idea, because Apple's imminent
deployment of classic ECN to millions of end hosts will break that
assumption.

A more robust deployment option would be to use a new transport protocol
ID.  Then it wouldn't be TCP any more, and you can throw away some cruft
while you're at it.  I'll leave the problems with that idea to your fertile
imaginations.

As a gentle reminder, ELR is designed to solve the same problem while
avoiding these deployment problems.  It does "burn" ECT(1), but for a good
cause and - crucially - doesn't require the network to be aware of it
before endpoints can safely turn it on.

- Jonathan Morton