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

["Black, David" <[e-mail]>]

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.

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."  ?

> 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?

> 
> 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-experimentation/
> >
> > 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
> >