Re: [aqm] ECT(1)

Bob Briscoe <research@bobbriscoe.net> Mon, 03 August 2015 23:23 UTC

Return-Path: <research@bobbriscoe.net>
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 308281B31F1 for <aqm@ietfa.amsl.com>; Mon, 3 Aug 2015 16:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 46R7dKbM7yZ1 for <aqm@ietfa.amsl.com>; Mon, 3 Aug 2015 16:23:28 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5241B31DB for <aqm@ietf.org>; Mon, 3 Aug 2015 16:23:27 -0700 (PDT)
Received: from 223.128.115.87.dyn.plus.net ([87.115.128.223]:39103 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <research@bobbriscoe.net>) id 1ZMP4m-0005nr-TZ; Tue, 04 Aug 2015 00:23:25 +0100
Message-ID: <55BFF7EC.1010608@bobbriscoe.net>
Date: Tue, 04 Aug 2015 00:23:24 +0100
From: Bob Briscoe <research@bobbriscoe.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: John Leslie <john@jlc.net>, "Scheffenegger, Richard" <rs@netapp.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>
In-Reply-To: <20150728145036.GK96964@verdi>
Content-Type: multipart/alternative; boundary="------------000705030401030707070006"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/wnlhmXtR4NY7G8CX2YTeeaSe_kA>
X-Mailman-Approved-At: Mon, 03 Aug 2015 16:38:44 -0700
Cc: Dave Taht <dave.taht@gmail.com>, "aqm@ietf.org" <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: Mon, 03 Aug 2015 23:23:32 -0000

John, Richard,

I do not believe an IP (v4) option or a v6 extension would be necessary. 
If ECT(1) were used that would surely be sufficient alone.

I believe the main criteria for an identifier for this new service are:
1. preferably orthogonal to Diffserv classes.
2. preferably end-to-end in scope
3. preferably classic (RFC168) ECN and 'L4S' ECN would not permanently 
burn two codepoints, since it seems that 'L4S' could eventually subsume 
classic ECN (a fork would not be needed, because classic ECN doesn't 
seem to do anything that L4S cannot do).

*ECT(1) **
*Seems a good identifier, but it has the following problems:

a) L4S traffic would need to be distinguished from classic ECN both when 
unmarked (ECT0 vs ECT1) and when marked (CE vs CE???). Ie. congestion 
experienced (CE) would have to be shared between the classes. It would 
not be so problematic if all queues classified all CE packets as the 
lowest latency class (L4S); CE packets from classic flows would then be 
delivered early out of order, requiring some buffering, but probably no 
more buffering than is already needed for retransmissions, and at least 
they would never be late out of order. See also {Note 1}.

b) ECT(1) is the last available ECN codepoint (for both v4 & v6). Using 
ECT(1) for L4S and ECT(0) for Classic ECN would burn the last codepoint 
just for migration purposes (contravening my criterion #3). If we could 
predict that migration might one day finish, we could foresee a time 
when ECT(0) might become available again. But that's a long shot.

c) For the record, the following uses of ECT(1) have been proposed by 
the IETF and by researchers:
* receiver cheat detection (the ECN nonce [RFC3540] - experimental)
* ECN path testing (ECN for RTP [RFC6679] - standards track)
* various intermediate congestion level proposals (including PCN 
[RFC6660] - standards track)
* various fast-start proposals (in research, e.g. VCP)

d) PCN is defined for a controlled environment, so that's not a problem. 
THe wording or RTP-ECN does not mandate the use of ECT(1), but it is not 
always clear that it is optional either. So I am trying to find out 
whether any implementations have used ECT(1). Even if none of the IETF 
uses of ECT(1) are problematic in practice, we should think very 
carefully before burning ECT(1) for L4S, because there do appear to be 
new uses being proposed for it that address a new potentially important 
class of problems: getting up to speed fast.

*DSCP**
*It might be better to distinguish L4S ECN from Classic ECN by using 
only ECT(0) and CE, but also using a distinctive DS codepoint for L4S. 
L4S could start off local-network only (e.g. for a network operator's 
premium services), or a global DSCP could be burned so that hosts could 
set it without needing to be configured for the network they happen to 
be connected to at any one time. Then, assuming all Classic ECN might 
eventually migrate to L4S ECN, a DSCP would no longer be needed as well 
as ECT(0) to identify L4S. Then the ECN field alone could represent L4S 
end-to-end.

We all know that DSCP has the following problems:
a) Diffserv is not orthogonal to Diffserv (obviously), so multiple DSCPs 
might be needed for L4S in each DS class
b) DS is not end-to-end
c) few global DSCPs left, altho certainly there are more DS codepoints 
than ECN codepoints left.

*Summary**
*Combining ECT(0) and CE with a globally assigned DSCP solely during 
initial deployment of L4S seems the least worst choice.


Bob

{Note 1} I'm sure some SDN-enabled equipment could easily decide which 
queue to classify CE packets into by classifying transport layer flows 
or the SPI of IPsec packets based on earlier ECT(1) or ECT(0) packets. 
However, we shouldn't and can't always rely on visibility of transport 
flows or on availability of SDN-capable hardware.


On 28/07/15 15:50, John Leslie wrote:
> Scheffenegger, Richard <rs@netapp.com> wrote:
>> Regarding the identifier to differentiate legacy ECN (cc reaction on
>> ECN per RTT = cc reaction to loss in RTT) and the differentiated
>> response (proportional to the # of CEs per RTT) is an open question.
>     Wide open!
>
>> Perhaps we can start to gather the views of the group on this list
>> already; There have been other uses for ECT(1) been proposed over
>> time, and it has also been pointed out that repurposing a DiffServ
>> Codepoint may not be the easierst to do from a procedural view.
>     Nor (IMHO) is a repurposed DiffServ Codepoint likely to work well.
>
>     OTOH, I think the time is ripe to deprecate ECN Nonce; and reserve
> ECT(1) for (currently) Experimental uses.
>
>     We could pretty easily combine that with an IP Option to define the
> particular experiment, and even record data about forwarding node action.
> (Admittedly, this is more difficult in IPv6, so I suggest initially
> considering IPv4; and then adding an IPv6 kludge, probably hop-by-hop.)
>
>     IMHO, the only other uses for ECT(1) that have approached "traction"
> relate to differentiation of forwarder action for ECN marking.
>
>> Also, I would like to encourage members of the aqm wg to review the various
>> versions of http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn
>> (the technical content did change in each version substantially).
>> Disclaimer, I'm one of the authors of that draft.
>     I believe I've reviewed them all; but is it truly reasonable to expect
> all WG members to review more than the latest one?
>
>     Fundamentally, the latest version calls for three counters, to be
> masked to low-order bits reporting changes in the counters. There are
> three possibilities on _where_ these bits will be reported. (I'd rather
> not bike-shed the virtues of each yet...)
>
>     draft-briscoe-aqm-dualq-coupled does not appear to have been posted
> yet: I'll be only too happy to discuss it once it is...
>
>     Fundamentally, it proposes to identify a separate low-latency queue
> which will report via ECN a near-zero-latency condition (vs. a zero
> congestion in this second queue), while the default queue operates by
> a legacy AQM mecanism, probably signaled by packet drop.
>
>     This strikes me as Experimental: there are a number of issues, such
> as how this low-latency queue overflows and what happens when it does,
> which need to be resolved before we could even consider Standards Track.
> At first blush, this looks like a good match for Experimental use of
> ECT(1).
>
> --
> John Leslie <john@jlc.net>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/