Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-07.txt

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

Bob,

Many thanks for giving this a careful review.  A -08 version is now needed – expect that to be posted sometime during the Singapore meeting week.

Comments inline …

Thanks, --David

From: Bob Briscoe [mailto:[e-mail]]
Sent: Thursday, November 2, 2017 1:36 PM
To: Black, David <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-07.txt

David,

Thank you very much for continuing to jump all the hurdles necessary to get this through the IESG.

As Spencer suggests, there have been sufficient text changes that this needs another sanity review.
I have checked through the diff and noticed the following.

Outside the new section 2.2, all the changes are editorial nits.
Within S.2.2, I've suggested some more significant changes, but they are still not changing the intent of what you typed.


2. ECN Experimentation: Overview

Congestion Response Differences:
CURRENT

      the proposal in the latter draft

      couples the sender congestion response change to Congestion

      Marking Differences changes
SUGGESTED:

      the proposal in the latter draft

      couples the difference in congestion response at the sender to different congestion

      marking in the network
RATIONALE:
I believe "...Differences changes..." was what the IESG found hard parse because it is a tautology resulting from quoting a heading verbatim.
[David>I see the concern: “changes” -> “functionality” should better disambiguate this.

Current:
    This is at variance with RFC 3168's requirement
SUGGESTED:
    These are at variance with RFC 3168's requirement
Rationale: There are 2 changes.
[David>] ACK: “This” -> “These changes”

Congestion Marking Differences:
CURRENT:
    is required for any sender congestion response used in this area of experimentation
SUGGESTED:
    is required for any differences in congestion marking or response used in this area of experimentation
[David>] Ok, original text was courtesy of sender congestion response being the focus in discussion.

2.2.  Considerations for Other Protocols

This new section is /very/ useful. The heading could be clearer though, perhaps:
    "Considerations for Nodes Not Involved in ECN Experiments"
[David>] This is getting wordy.  Perhaps “Network Considerations for ECN Experimentation” and then make “not involved” clearer in the body of the section.

The context of the first 3 bullets is the opposite of the context of the rest of the doc. So I suggest that each bullet reminds the reader that the subject is "implementations not involved in experiments". Also some bullets are in the passive without a clear statement of what type of node the bullet applies to, which makes this problem worse.
[David>] Taking a fresh look at the list, bullets #4 and #5 seem to be different in scope and level of emphasis from the first 3.   I’ll move #4 and #5 to stand-alone paragraphs, so that “not involved in experiments” can then be in the lead-in text that covers the first 3 bullets.

Items #2 & #3 are troubling for three further reasons:
a) Congestion Response Differences experiments will not cause ECN and drop to no longer be equivalent.
b) The sender can still rely on this equivalence if it uses ECT(0).
c) Item #3 reads like nothing at all MUST originate ECT(1).

Any simple attempt to focus item #2 only on ECT(1), contradicts item #3. So I've suggested you reverse the order and edit as follows:

CURRENT:

   2.  The ECN CE codepoint SHOULD NOT be assumed to indicate that the

       packet would have been dropped if ECN were not in use, as that is

       not the case for either Congestion Response Differences

       experiments (see Section 4.1<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.1> below) or Congestion Marking

       Differences experiments (see Section 4.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.2> below).

   3.  Traffic marked with ECT(1) MUST NOT be originated, as specified

       in Section 4.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.2> below.
SUGGESTED:

   2.  A host not involved in experiments MUST NOT originate

       traffic marked with ECT(1), as specified

       in Section 4.2 below.

[David>] It’s more than hosts, as routers can originate traffic for purposes such as control and management.

   3.  If a host does send packets as ECT(1), it SHOULD NOT assume that the ECN CE codepoint indicates that the

       packet would have been dropped if ECN were not in use, as that is

       not the case for Congestion Marking

       Differences experiments (see Section 4.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.2> below).

[David>] This proposed change is actually wrong in limiting the scope to hosts, as the more valuable guidance is to nodes in the network that forward CE packets.  RFC 3168 encourages the presumption that CE packets are drop-equivalent implies and hence are ok to drop in the network if it would be inconvenient to forward them.  That’s now a bad idea (need more than “inconvenient to forward” as justification for dropping), hence the “SHOULD NOT” statement.

Next, the subject of item #4 switches to nodes running experiments, but without saying so...
[David>] Not exactly, this is more about middleboxes that believe they are all-knowing about what protocols like TCP and RTP do, and hence drop packets that use ECN where it’s not supposed to be used. Complaints about bad middlebox behavior should be sent to /dev/null, please.  However …

CURRENT:

   4.  ECN may now be used on packets where it has not been used

       previously, specifically TCP control packets and retransmissions,

       see Section 4.3<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.3> below, and in particular its new requirements for

       middlebox behavior.  In general, any system or protocol that

       inspects or monitors network traffic SHOULD be prepared to

       encounter ECN usage on packets and traffic that currently do not

       use ECN.
SUGGESTED:

   4.  ECN experiments may use ECN on packets where it has not been used

       previously, specifically TCP control packets and retransmissions,

       see Section 4.3<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.3> below, and in particular its new requirements for

       middlebox behavior.  In general, any system or protocol that

       inspects or monitors network traffic SHOULD be prepared to

       encounter ECN usage on packets that currently do not use ECN.

[David>] That helps, I will make that change.

Item #5 doesn't say what the experiments might change (or not) about tunnelling.

CURRENT:

   5.  Requirements for handling of the ECN field by tunnel

       encapsulation and decapsulation are specified in [RFC6040<https://tools.ietf.org/html/rfc6040>].

       Additional related guidance can be found in

       [I-D.ietf-tsvwg-ecn-encap-guidelines<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-ecn-encap-guidelines>] and

       [I-D.ietf-tsvwg-rfc6040update-shim<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-rfc6040update-shim>].
SUGGESTED:

   5.  Requirements for handling of the ECN field by nodes

       encapsulatng or decapsulating outer IP headers are specified in [RFC6040<https://tools.ietf.org/html/rfc6040>],

       which is in the process of being updated by

       [I-D.ietf-tsvwg-rfc6040update-shim<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-rfc6040update-shim>].

       Related guidance for encapsulations with non-IP outer headers can be found in

       [RFC5129], [I-D.ietf.trill-ecn-support], [I-D.ietf-tsvwg-ecn-encap-guidelines<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-ecn-encap-guidelines>].

       It is intended that ECN experiments will have to to work without

       changing these existing encapsulation behaviors.

[David>] Yes, and in particular, the last sentence is definitely a useful addition.  I will pick this up, with some editing.

2.3.  Operational and Management Considerations

I like this a lot too. But a nit:

CURRENT:

the questions in Appendix A<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#appendix-A>
SUGGESTED:

the questions in Appendix A<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#appendix-A> of RFC 5706

[David>] ACK, will do.

2.4

CURRENT:

   The second codepoint, ECT(1), is used to support ECN nonce

   functionality that discourages receivers from exploiting ECN to
SUGGESTED:

   RFC 3168 assigns the second codepoint, ECT(1), to support ECN nonce

   functionality to discourage receivers from exploiting ECN to
RATIONALE:
Next sentence says the nonce isn't used, so it's confusing here to say it is used.
[David>] Will do, with “assigns” -> “assigned”


CURRENT:

   4.  Remove the first two paragraphs of Section 20.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-20.2>, which discuss

       the ECN nonce and alternatives.  No changes are made to the rest

       of Section 20.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-20.2>, which discusses alternate uses for the fourth

       ECN codepoint.
SUGGESTED:

   4.  Remove the first paragraph of Section 20.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-20.2>, which discuss

       the ECN nonce and alternatives.  No changes are made to the rest

       of Section 20.2<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-20.2>, which discusses alternative uses for the fourth

       ECN codepoint.
RATIONALE: Pls don't remove the 2nd para of S.20.2, which is a good alternative to the ECN nonce.
In fact, we need this 2nd para, so we can refer to it from Appendix C.1 of draft-ietf-tsvwg-ecn-l4s-id
instead of using the expired individual draft draft-moncaster-tcpm-rcv-cheat
[David>] Hmm – I think that 2nd paragraph does have to come out.   I suggest either referencing RFC 3168 as originally published, and/or copying that text into the l4s-id draft with attribution of source.

(Also note the nit: alternate means alternating).
[David>] ACK


4.1 Congestion Response Differences

CURRENT:

     Hence an ECN congestion indication communicates a

   higher likelihood that a shorter queue exists at the network

   bottleneck node by comparison to a packet drop that indicates

   congestion [I-D.ietf-tcpm-alternativebackoff-ecn<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tcpm-alternativebackoff-ecn>].
SUGGESTED:

     Hence an ECN congestion indication communicates that

   there will not be an excessively long queue at the network

   bottleneck node, [I-D.ietf-tcpm-alternativebackoff-ecn<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tcpm-alternativebackoff-ecn>]

   whereas a packet drop communicates nothing about the length of

   a queue.
RATIONALE:
A drop could be from:
* an AQM that does not support ECN (for instance DOCSIS AQMs do not define ECN support). Then the queue would be the same length as if a CE mark had been emitted (ABE works with equivalence of CE and drop).
* a rate policer that has no queue at all.
[David>] That doesn’t vitiate the “higher likelihood” language.  No change needed here.


4.2 Congestion Marking Differences

CURRENT:

   Use of different ECN codepoints is a promising means of

   identifying these two classes of traffic to network nodes, and hence

   this area of experimentation is based on the use of the ECT(1)

   codepoint to request ECN congestion marking behavior in the network

   that differs from ECT(0) counterbalanced by use of a different IETF-

   approved congestion response to CE marks at the sender, e.g., as

   proposed in [I-D.ietf-tsvwg-ecn-l4s-id<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-ecn-l4s-id>].
SUGGESTED:

   Use of different ECN codepoints is a promising means of

   identifying these two classes of traffic to network nodes, and hence

   this area of experimentation is based on the use of the ECT(1)

   codepoint to request ECN congestion marking behavior in the network

   that differs from ECT(0). This would need to be counterbalanced by

   use of a different IETF-approved congestion response to CE marks

   at the sender, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#ref-I-D.ietf-tsvwg-ecn-l4s-id>].
RATIONALE:
Splits v long sentence.
[David>] Ok, but use of “would” is too weak – I will split sentence and make it clear that the different congestion response is necessary.





Bob

On 01/11/17 18:08, Black, David wrote:
Hi Spencer,

Well, I’m pleasantly surprised that Benoit cleared his Discuss with a simple note of thanks and no further text change requests.

I’ve checked the -07 vs. -06 diff, and it looks good to me, and I concur with your assumption that the RFC Editor will fix the “primary” -> “primarily” problem.

I believe that Gorry (as shepherd) is also fine with this -07 version, but I suggest giving him an opportunity to double-check before pushing the approve-for-publication button.

And yes … I’m definitely pleased to have reached this stage in the process.

Thanks, --David

From: Spencer Dawkins at IETF [mailto:[e-mail]]
Sent: Tuesday, October 31, 2017 5:11 PM
To: Black, David <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-07.txt

Hi, David,

On Sat, Oct 21, 2017 at 12:37 PM, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
This draft contains changes resulting from IESG Evaluation.

See the change history for a summary of what's been done, including the addition of sections 2.2 and 2.3 and movement of section 4.4 on the requirement for effective congestion control to section 2.1

Thanks, --David

Hi, David,

I see that Benoit has cleared his Discuss based on -07, but remember that you mentioned kinda expecting that a -08 might be required, just based on the amount of new text that was added in -07.

Does it still seem that way to you (and, of course, to your document shepherd)?

I did see one typo in the new text,

"transition from current ECN functionality falls primary upon" should probably be

"transition from current ECN functionality falls primarily upon"

but that's easily fixed in an RFC Editor Note, if you don't need to submit an updated draft.

Just let me know!

And thanks for horsing that through.

Spencer

> -----Original Message-----
> From: I-D-Announce [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of
> [e-mail]<mailto:[e-mail]>
> Sent: Friday, October 20, 2017 5:46 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: I-D Action: draft-ietf-tsvwg-ecn-experimentation-07.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the
> IETF.
>
>         Title           : Relaxing Restrictions on Explicit Congestion Notification (ECN)
> Experimentation
>         Author          : David Black
>       Filename        : draft-ietf-tsvwg-ecn-experimentation-07.txt
>       Pages           : 21
>       Date            : 2017-10-20
>
> Abstract:
>    This memo updates RFC 3168, which specifies Explicit Congestion
>    Notification (ECN) as an alternative to packet drops for indicating
>    network congestion to endpoints.  It relaxes restrictions in RFC 3168
>    that hinder experimentation towards benefits beyond just removal of
>    loss.  This memo summarizes the anticipated areas of experimentation
>    and updates RFC 3168 to enable experimentation in these areas.  An
>    Experimental RFC in the IETF document stream is required to take
>    advantage of any of these enabling updates.  In addition, this memo
>    makes related updates to the ECN specifications for RTP in RFC 6679
>    and for DCCP in RFC 4341, RFC 4342 and RFC 5622.  This memo also
>    records the conclusion of the ECN nonce experiment in RFC 3540, and
>    provides the rationale for reclassification of RFC 3540 as Historic;
>    this reclassification enables new experimental use of the ECT(1)
>    codepoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-
> experimentation-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-07
>
>
> 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<http://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]<mailto:[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