Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt

"Black, David" <David.Black@dell.com> Sat, 29 October 2016 00:55 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129512951D; Fri, 28 Oct 2016 17:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=GJaj+S19; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=bbOu4bod
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 DUGfJ7iBp2fm; Fri, 28 Oct 2016 17:55:47 -0700 (PDT)
Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 0A0AA128E18; Fri, 28 Oct 2016 17:55:46 -0700 (PDT)
DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=LZdS90fE+BTyk8/f0eoTuY9LNI1GeuRb7QaUnNxiT/nc+hjv8hR2Pklm u0ugc+LzWv6Xhhr0zpsE1Q0spGbu5rrreznr1sLzW/EAqYuAWJGrLTVhG IcS7nvHUbj3Tj/AZOJlXLg42yPyRBcrmtBqZ3YFJ0cFtG/Bop7Vgrb9hT Q=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477702547; x=1509238547; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2ghkFxgMFH1pQfp7aPPjJkv7dp/VRcei2lqfpKoeQus=; b=GJaj+S19Ox+wCE6hjrTcvMXg+KvyiO5/Q6pZYAP9tcBLbVP1Iei/tdbt lGA33xBJn9efhyclNXBW5lzXCqIn8beCdoKiMHYYkhK+Ho/fdjPoNEwJq waN6jMo6HrvQtQ6K0PmTPQAxuo/mhu2R1/Q9IOtj7cn2rpBynGqWB3ch7 Y=;
Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 19:55:46 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2016 06:55:44 +0600
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0teiq006774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 20:55:43 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u9T0teiq006774
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477702544; bh=28QaWZk1YGNXtYIDsH9kkFFw9Fw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bbOu4bodM6lRhC2y+TD6A50qka63rcglFiLJxMKK4ZeXIgqm/ndenbMP8b7pvesqX mjj1eVq9BY6scinegB5ykQkdHDusIxnH/F6yx1m9TioPxYJNbfGsXumq16DZYXmOWz tec9lDOs8OXWPhWzTFEt1zfu7GGlbFHHhuPx+8Pk=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u9T0teiq006774
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 28 Oct 2016 20:55:22 -0400
Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0tMCo003923 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 28 Oct 2016 20:55:22 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0266.001; Fri, 28 Oct 2016 20:55:21 -0400
To: Bob Briscoe <in@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>, "tcpPrague@ietf.org" <tcpPrague@ietf.org>
Thread-Topic: [tsvwg] [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt
Thread-Index: AQHSJmYvj8ED7chUmECqekIdzFz9XaCrZRqggAzRJoCABnbmwA==
Date: Sat, 29 Oct 2016 00:55:20 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F700048@MX307CL04.corp.emc.com>
References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> <CE03DB3D7B45C245BCA0D243277949362F6B60ED@MX307CL04.corp.emc.com> <DB4PR07MB3482CDD877C9870E0CC7093C2C70@DB4PR07MB348.eurprd07.prod.outlook.com> <CE03DB3D7B45C245BCA0D243277949362F6C4DE2@MX307CL04.corp.emc.com> <DB4PR07MB3480F87F3FDA3FDB86D8431C2C60@DB4PR07MB348.eurprd07.prod.outlook.com> <CE03DB3D7B45C245BCA0D243277949362F6C766C@MX307CL04.corp.emc.com> <BF6B00CC65FD2D45A326E74492B2C19FB775C0FF@FR711WXCHMBA05.zeu.alcatel-lucent.com> <CE03DB3D7B45C245BCA0D243277949362F6DB8B7@MX307CL04.corp.emc.com> <379e8b8a-734e-04ee-c3cb-f1c428b21e38@bobbriscoe.net>
In-Reply-To: <379e8b8a-734e-04ee-c3cb-f1c428b21e38@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/djJh10wFnuKXOmsLrLH_QYoTmTE>
Cc: "Black, David" <David.Black@dell.com>
Subject: Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2016 00:55:50 -0000

Bob,

Thanks for this follow-up.

[1] Should ECT(1) be Reserved now?

At this point, I think this issue ought to go to the Seoul TSVWG meeting, so
the -02 version, will contain the current RFC 3168  "SHOULD use" for ECT(0), and
indicate that whether that ought to become a "MUST use" for ECT(0) is an open
issue.

[2] Relationship of L4S to Alternate Backoff

Thanks for the L4S draft reference, there will be text in the -02 of the ECN
experimentation draft on this.

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe [mailto:in@bobbriscoe.net]
> Sent: Monday, October 24, 2016 1:57 PM
> To: Black, David; De Schepper, Koen (Nokia - BE); Ingemar Johansson S;
> tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org
> Subject: Re: [tsvwg] [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-
> experimentation-00.txt
> 
> David,
> 
> A couple of responses inline...
> 
> On 16/10/16 19:21, Black, David wrote:
> > [1]
> >
> >> I agree with Ingemar that the text:
> >>       "Unless otherwise specified by an Experimental RFC, routers treat
> >>        the ECT(0) and ECT(1) codepoints as equivalent, and senders are
> >>        free to use either the ECT(0) or the ECT(1) codepoint to indicate
> >>        ECT, on a packet-by-packet basis."
> >> Should better become:
> >>       "Unless otherwise specified by an Experimental RFC, routers treat
> >>        the ECT(0) and ECT(1) codepoints as equivalent, and senders should
> >>        use only the ECT(0) codepoint to indicate ECT."
> >> There is no reason anymore to use ECT(1) by senders, unless an Experimental
> >> RFC specifies differently.
> > Ok.
> >
> > [... snip...]
> >
> >> I think it is clearer to explicitly state that only ECT(0) should be used.
> > That's already been done in -00, via section 3 quoting this stronger text
> > from RFC 3168:
> >
> >        Protocols and senders that only require a single ECT codepoint
> >        SHOULD use ECT(0).
> >
> > That should suffice.
> [BB] If we're going to rely on that sentence, we need to add your
> exception for experimental RFCs to it. Then it becomes:
> 
>        "Unless otherwise specified by an Experimental RFC, when the ECN
>        nonce has not already been implemented, protocols and senders MUST
>        solely use ECT(0)."
> 
> The SHOULD has to turn into a MUST, because all the possible exceptions
> that the original SHOULD allowed are now listed explicitly in the
> sentence, leaving no other exceptions that you want to allow.
> 
> >
> > [2]
> >
> >> I think we need to clarify if the text in this section is intended only
> >> for responses in the sender "without" a compensating change in the network
> >> between drop and CE marks, or also "with" a compensation. In the first case
> >> we should also specify this, and in the second case we just can also refer
> >> to the L4S draft (where we assume a DCTCP or TCP-Prague response).
> > Which L4S draft should be referenced?  I believe I agree in general with the
> > above concern, but I need to know which L4S draft should be referenced on
> > the "with" approach in order to write the actual text for the ECN
> Experimentation
> > draft.
> [BB] draft-briscoe-tsvwg-ecn-l4s-id-01 has the text you need.
> It attempts to specify both the difference in network behaviour and
> sender behaviour that is associated with ECT(1).
> 
> Specifically, our current attempt to specify the transport behaviour is in:
> https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-2.3
> 
> 
> 
> Cheers
> 
> 
> 
> Bob
> >
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-bell-
> >> labs.com]
> >> Sent: Friday, October 14, 2016 5:59 PM
> >> To: Black, David; Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org;
> >> tcpPrague@ietf.org
> >> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-
> experimentation-
> >> 00.txt
> >>
> >> Hi all,
> >>
> >> Thanks David, I think this draft is useful to support further L4S
> >> specifications.
> >>
> >> Some excerpts and comments from the mails below:
> >>
> >> I agree with Ingemar that the text:
> >>       "Unless otherwise specified by an Experimental RFC, routers treat
> >>        the ECT(0) and ECT(1) codepoints as equivalent, and senders are
> >>        free to use either the ECT(0) or the ECT(1) codepoint to indicate
> >>        ECT, on a packet-by-packet basis."
> >> Should better become:
> >>       "Unless otherwise specified by an Experimental RFC, routers treat
> >>        the ECT(0) and ECT(1) codepoints as equivalent, and senders should
> >>        use only the ECT(0) codepoint to indicate ECT."
> >> There is no reason anymore to use ECT(1) by senders, unless an Experimental
> >> RFC specifies differently.
> >>
> >>> I've revised my working version of the -01 draft to remove the second
> >>> sentence as part of this proposed update to RFC 3168.
> >> I think it is clearer to explicitly state that only ECT(0) should be used.
> >>
> >>> My understanding is that L4S requires both ECT(0) and ECT(1), as it couples
> >>> treatments of traffic marked with those codepoints.  For that reason, the
> >>> statement in section 3 (which is quoted from RFC 3168) does not apply to
> L4S.
> >> L4S is not changing the meaning of non-ECT or ECT(0) packets.
> >> It still assumes a response by the sender equal as a response to drop. The
> >> coupling is only towards ECT(1). Routers will more frequently mark ECT(1)
> >> packets to compensate the more aggressive behavior of L4S. ECT(1) marking
> >> is steered by the non-ECT drop and ECT(0) marking probability such that
> >> flow rates become equal independent of (non-)ECT(0/1).
> >>
> >>> The handling of ECT(0) and non-ECT packets goes outside the L4S definition
> >> Correct. Nothing changes for L4S.
> >>
> >>> [2] Section 2 - L4S and description of Alternative Backoff.  If one of the
> >>> folks directly involved in L4S would like to suggest a draft to cite that
> >>> describes the L4S backoff for the low latency/higher-CE-marking-probability
> >>> functionality
> >> Technically speaking L4S has an alternative response to a CE marked packet,
> >> but only to a packet that was sender-marked as ECT(1) and when the network
> >> marks packets more frequently by the routers.
> >>
> >> I think we need to clarify if the text in this section is intended only
> >> for responses in the sender "without" a compensating change in the network
> >> between drop and CE marks, or also "with" a compensation. In the first case
> >> we should also specify this, and in the second case we just can also refer
> >> to the L4S draft (where we assume a DCTCP or TCP-Prague response).
> >>
> >> Regards,
> >> Koen.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Black,
> >>> David
> >>> Sent: vrijdag 7 oktober 2016 18:29
> >>> To: Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org;
> >>> tcpPrague@ietf.org
> >>> Cc: Black, David
> >>> Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-
> >>> experimentation-00.txt
> >>>
> >>> Ingemar,
> >>>
> >>> Summarizing:
> >>>
> >>> [1] Section 4.2 - "free to use" text.  The full quote from RFC 3168 is:
> >>>
> >>> 	"Routers treat the ECT(0) and ECT(1) codepoints as equivalent.
> >>> Senders are free to use either the ECT(0)
> >>> 	 or the ECT(1) codepoint to indicate ECT, on a packet-by-packet
> >>> basis."
> >>>
> >>> I've revised my working version of the -01 draft to remove the second
> >>> sentence as part of this proposed update to RFC 3168.  That's both simpler
> >>> and clearer than what's in the posted -00.  In addition, doing this obviates
> >>> the need to say anything in this section about the possible L4S
> >>> relationships between the ECT(0) and ECT(1) queues.
> >>>
> >>> [2] Section 2 - L4S and description of Alternative Backoff.  If one of the
> >>> folks directly involved in L4S would like to suggest a draft to cite that
> >>> describes the L4S backoff for the low latency/higher-CE-marking-probability
> >>> functionality, I'm happy to cite that as an additional example of
> >>> Alternative Backoff.
> >>>
> >>> Thanks, --David
> >>>
> >>>> -----Original Message-----
> >>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
> >>>> Sent: Friday, October 07, 2016 2:38 AM
> >>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org
> >>>> Cc: Ingemar Johansson S
> >>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-
> >>> experimentation-
> >>>> 00.txt
> >>>>
> >>>> Hi
> >>>>
> >>>> Comments inline [IJ]
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Black, David [mailto:David.Black@dell.com]
> >>>>> Sent: den 7 oktober 2016 02:28
> >>>>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>;
> >>>>> tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org
> >>>>> Cc: Black, David <David.Black@dell.com>
> >>>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-
> >>>>> experimentation-00.txt
> >>>>>
> >>>>> Hi Ingemar,
> >>>>>
> >>>>> David> Inline
> >>>>>
> >>>>> Thanks, --David
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
> >>>>>> Sent: Thursday, October 06, 2016 4:32 AM
> >>>>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org;
> >>>>>> tcpPrague@ietf.org
> >>>>>> Cc: Ingemar Johansson S
> >>>>>> Subject: RE: [tcpPrague] FW: I-D Action:
> >>>>>> draft-black-tsvwg-ecn-experimentation-
> >>>>>> 00.txt
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> Thanks for writing up this draft. I have some comments on the contents
> >>>>> Thanks for carefully reading the draft.
> >>>>>
> >>>>>> Intended status : Standards track. I interpret this that it means that
> >>>>>> this document becomes standards track.
> >>>>>> Are there any ideas around the intended status for a document such as
> >>>>>> briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ?
> >>>>> Possibly - I don' t know.  The ecn-experimentation draft is not intended
> >>> to
> >>>>> settle that question for the l4s-id draft or any of the other drafts
> >>> involved in
> >>>>> the described areas of experimentation.
> >>>>>
> >>>>> I wrote the ecn-experimentation draft to allow the experiments to be
> >>>>> specified in Experimental RFCs without each experiment also needing a
> >>>>> companion Standards
> >>>>> Track RFC just to open up space for the experiment.   If any of the
> >>>>> experiments
> >>>>> pan out so well that they deserve to be immediately written up as a
> >>>>> Standards Track RFC without bothering with an Experimental RFC, then
> >>> that
> >>>>> would be wonderful, IMHO.
> >>>>>
> >>>>>> Section 4.2 : " "Unless otherwise specified by an Experimental RFC,
> >>> routers
> >>>>> treat
> >>>>>>        the ECT(0) and ECT(1) codepoints as equivalent, and senders are
> >>>>>>        free to use either the ECT(0) or the ECT(1) codepoint to
> >>> indicate
> >>>>>>        ECT, on a packet-by-packet basis.""
> >>>>>> In some way I find it to contradict the proposed statement in  section
> >>> 3 "
> >>>>>> Protocols and senders that only require a single ECT codepoint  SHOULD
> >>>>>> use ECT(0)."
> >>>>>> I see here a risk that the statement in 4.2 can delay deployment of
> >>>>>> L4S capability based on the use of ECT(1) in the networks ?
> >>>>> My understanding is that L4S requires both ECT(0) and ECT(1), as it
> >>> couples
> >>>>> treatments of traffic marked with those codepoints.  For that reason,
> >>> the
> >>>>> statement in section 3 (which is quoted from RFC 3168) does not apply to
> >>> L4S.
> >>>> [IJ] It is perhaps here I see things differently.
> >>>> My interpretation is that L4S is that senders mark packets with some
> >>> special
> >>>> codepoint (let's call it ECT(1) ) and network queues detect this and send
> >>> the
> >>>> packets to a dedicated queue which marks these packets to ECN-CE at a
> very
> >>> low
> >>>> queue delay. A special case may be that senders are networks are 100% L4S
> >>> (Data
> >>>> centers), this means that only the code point ECT(1) is in use.
> >>>> The handling of ECT(0) and not-ECT packets goes outside the L4S definition
> >>> and
> >>>> definitely requires dualQ solution and classification.
> >>>> It is quite possible that my interpretation is flawed.
> >>>>
> >>>>> OTOH, I see your concern, namely that "free to use" in the RFC 3168 text
> >>>>> quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC
> >>> 3168
> >>>>> text quoted in section 3.  This is a concern with RFC 3168 itself.
> >>>>>
> >>>>> Would it help for this ecn-experimentation draft to update RFC 3168 by
> >>>>> removing the words "and senders are free to use either the ECT(0) or the
> >>>>> ECT(1) codepoint to indicate ECT, on a packet-by-packet basis."  ?
> >>>> [IJ] Yes, it probably solves things, mind though that reason why I brought
> >>> this is
> >>>> up is that I may interpret the definition of L4S differently.
> >>>>
> >>>>>> Section 5 : I see the main problem with RFC6679 (in this context) in
> >>>>>> the use of the nonce. Don't however see any major problem to use
> >>>>>> feedback also for an L4S capable sender/receiver using ECT(1).
> >>>>>> For that purpose it may be better to rewrite :
> >>>>>>        Use of ECT(1) and random ECT values is discouraged, as that may
> >>>>>>        expose RTP to differences in network treatment of ECT(1) and
> >>>>>>        ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id].
> >>>>>> To :
> >>>>>>        Use of ECT values is discouraged, as that may
> >>>>>>        expose RTP to differences in network treatment of ECT(1) and
> >>>>>>        ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id].
> >>>>> Good point - I agree.  I would insert "random" after "Use of" in the
> >>> "To:" text.
> >>>>> I'll make that change in my working copy that will become -01.
> >>>>>
> >>>>>> Further ... quote " In support of Alternative Backoff experimentation
> >>>>>> ...". I would say that this applies to L4S as well. As an example,
> >>>>>> SCReAM (RMCAT WG congestion control candidate) is easily modified to
> >>>>>> support L4S, and the RFC6679 feedback can be used with SCReAM. For
> >>>>>> that reason it may be better to rephrase it like " In support of
> >>>>>> Alternative Backoff experimentation and experiments based on
> >>>>>> [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar
> >>>>> I'd prefer to do something different.   I think L4S is an example of
> >>> both the
> >>>>> Alternative
> >>>>> Backoff and ECT Differences areas of experimentation, and hence I'd
> >>> suggest
> >>>>> citing an L4S draft in the description of the Alternative Backoff
> >>> experiment
> >>>>> scope in Section 2.  Which L4S draft would you suggest?
> >>>> [IJ] Good question.. Not sure what is required here?. Our proprietary
> >>> SCReAM
> >>>> research code has support for L4S, one possibility is to update the SCReAM
> >>> draft
> >>>> with a description of this functionality. An example was shown at the L4S
> >>> BoF
> >>>> (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4s-
> >>> 2.pdf )
> >>>>>> Regards
> >>>>>> /Ingemar
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Black, David [mailto:David.Black@dell.com]
> >>>>>>> Sent: den 1 oktober 2016 00:42
> >>>>>>> To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org
> >>>>>>> Cc: Black, David <David.Black@dell.com>
> >>>>>>> Subject: [tcpPrague] FW: I-D Action:
> >>>>>>> draft-black-tsvwg-ecn-experimentation-
> >>>>>>> 00.txt
> >>>>>>>
> >>>>>>> This is the process-oriented draft on ECN experimentation that I
> >>>>>>> promised at the TSVWG
> >>>>>>> meeting in Berlin.   Comments are welcome, but please keep the
> >>> process
> >>>>>>> focus in mind -
> >>>>>>> the intent is to leave documentation of the actual ECN changes and
> >>>>>>> rationale to the referenced drafts that document the ECN
> >>> experiments.
> >>>>>>> Thanks, --David
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On
> Behalf
> >>>>>>> Of internet-drafts@ietf.org
> >>>>>>> Sent: Friday, September 30, 2016 6:24 PM
> >>>>>>> To: i-d-announce@ietf.org
> >>>>>>> Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt
> >>>>>>>
> >>>>>>>
> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>>>> directories.
> >>>>>>>
> >>>>>>>          Title           : Explicit Congestion Notification (ECN)
> >>> Experimentation
> >>>>>>>          Author          : David Black
> >>>>>>> 	Filename        : draft-black-tsvwg-ecn-experimentation-00.txt
> >>>>>>> 	Pages           : 10
> >>>>>>> 	Date            : 2016-09-30
> >>>>>>>
> >>>>>>> Abstract:
> >>>>>>>     Multiple protocol experiments have been proposed that involve
> >>>>> changes
> >>>>>>>     to Explicit Congestion Notification (ECN) as specified in RFC
> >>> 3168.
> >>>>>>>     This memo summarizes the proposed areas of experimentation to
> >>>>> provide
> >>>>>>>     an overview to the Internet community and updates RFC 3168, a
> >>>>>>>     Proposed Standard RFC, to allow the experiments to proceed
> >>> without
> >>>>>>>     requiring a standards process exception for each Experimental RFC
> >>> to
> >>>>>>>     update RFC 3168.  This memo also makes related updates to the ECN
> >>>>>>>     specification for RTP in RFC 6679 for the same reason.  Each
> >>>>>>>     experiment is still required to be documented in an Experimental
> >>> RFC.
> >>>>>>>     This memo also records the conclusion of the ECN Nonce experiment
> >>> in
> >>>>>>>     RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic.
> >>>>>>>
> >>>>>>>
> >>>>>>> The IETF datatracker status page for this draft is:
> >>>>>>> https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentati
> >>>>>>> on/
> >>>>>>>
> >>>>>>> There's also a htmlized version available at:
> >>>>>>> https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00
> >>>>>>>
> >>>>>>>
> >>>>>>> Please note that it may take a couple of minutes from the time of
> >>>>>>> submission until the htmlized version and diff are available at
> >>>>> tools.ietf.org.
> >>>>>>> Internet-Drafts are also available by anonymous FTP at:
> >>>>>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> I-D-Announce mailing list
> >>>>>>> I-D-Announce@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>>>
> >>> _______________________________________________
> >>> tcpPrague mailing list
> >>> tcpPrague@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tcpprague
> >
> 
> --
> ______________________________________________________________
> __
> Bob Briscoe                               http://bobbriscoe.net/