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

"De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com> Fri, 14 October 2016 21:59 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.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 757E71298CE; Fri, 14 Oct 2016 14:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FnJJxk-uGr0N; Fri, 14 Oct 2016 14:59:01 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A9A9B1298D1; Fri, 14 Oct 2016 14:59:00 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 246185D302017; Fri, 14 Oct 2016 21:58:54 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9ELwv8I018404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 21:58:58 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9ELwv3w005436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Oct 2016 23:58:57 +0200
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.121]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 23:58:57 +0200
From: "De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com>
To: "Black, David" <David.Black@dell.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: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt
Thread-Index: AQHSH6wWI61lpnnM/Uu82quAPO1dcqCcAoAAgABnWQCAAKUgAIALKVnQ
Date: Fri, 14 Oct 2016 21:58:56 +0000
Message-ID: <BF6B00CC65FD2D45A326E74492B2C19FB775C0FF@FR711WXCHMBA05.zeu.alcatel-lucent.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>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F6C766C@MX307CL04.corp.emc.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/mUOOURikPvGvUR6u0X4vzRxALrg>
Subject: Re: [tcpPrague] 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: Fri, 14 Oct 2016 21:59:04 -0000

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