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

[Bob Briscoe <[e-mail]>]

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; [e-mail]; [e-mail];
>> [e-mail]
>> 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:[e-mail]] On Behalf Of Black,
>>> David
>>> Sent: vrijdag 7 oktober 2016 18:29
>>> To: Ingemar Johansson S; [e-mail]; [e-mail];
>>> [e-mail]
>>> 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:[e-mail]]
>>>> Sent: Friday, October 07, 2016 2:38 AM
>>>> To: Black, David; [e-mail]; [e-mail]; [e-mail]
>>>> 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:[e-mail]]
>>>>> Sent: den 7 oktober 2016 02:28
>>>>> To: Ingemar Johansson S <[e-mail]>;
>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>> Cc: Black, David <[e-mail]>
>>>>> 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:[e-mail]]
>>>>>> Sent: Thursday, October 06, 2016 4:32 AM
>>>>>> To: Black, David; [e-mail]; [e-mail];
>>>>>> [e-mail]
>>>>>> 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:[e-mail]]
>>>>>>> Sent: den 1 oktober 2016 00:42
>>>>>>> To: [e-mail]; [e-mail]; [e-mail]
>>>>>>> Cc: Black, David <[e-mail]>
>>>>>>> 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:[e-mail]] On Behalf
>>>>>>> Of [e-mail]
>>>>>>> Sent: Friday, September 30, 2016 6:24 PM
>>>>>>> To: [e-mail]
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>

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