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

From: "Black, David" <[email-masked]>
Date: Wed, 1 Nov 2017 18:08:41 +0000

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:[email-masked]]
Sent: Tuesday, October 31, 2017 5:11 PM
To: Black, David <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> Sent: Friday, October 20, 2017 5:46 PM
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> 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
> [email-masked]<mailto:[email-masked]>
> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Nov 2017 09:02:23 -0500

Dear Both,

On Wed, Nov 1, 2017 at 1:08 PM, Black, David <[email-masked]> 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.
>

Gorry, I'll add the RFC Editor Note for this, and await your confirmation.

Thanks,

Spencer

> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* Tuesday, October 31, 2017 5:11 PM
> *To:* Black, David <[email-masked]>
> *Cc:* [email-masked]
> *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 <[email-masked]>
> wrote:
>
> 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.
>
>
>
> > From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > To: [email-masked]
> > Cc: [email-masked]
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 2 Nov 2017 17:36:25 +0000

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.

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.

*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

*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"

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.

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 (seeSection 4.1 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.1>  below) or Congestion Marking
        Differences experiments (seeSection 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
        inSection 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.
    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 (seeSection 4.2 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#section-4.2>  below).

Next, the subject of item #4 switches to nodes running experiments, but 
without saying so...

CURRENT:

    4.  ECN may now be used on packets where it has not been used
        previously, specifically TCP control packets and retransmissions,
        seeSection 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,
        seeSection 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.

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.

*2.3.  Operational and Management Considerations**
*
I like this a lot too. But a nit:

CURRENT:

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

SUGGESTED:

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

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.

CURRENT:

    4.  Remove the first two paragraphs ofSection 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
        ofSection 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 ofSection 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
        ofSection 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

(Also note the nit: alternate means alternating).

*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.

*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.

Bob

On 01/11/17 18:08, Black, David wrote:
> 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.
>
> *From:*Spencer Dawkins at IETF [mailto:[email-masked]]
> *Subject:* Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-ecn-experimentation-07.txt
>
> Hi, David,
>
>     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.
>
>     > From: I-D-Announce [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of
>     > [email-masked] <mailto:[email-masked]>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <http://www.ietf.org/shadow.html>

---

From: "Black, David" <[email-masked]>
Date: Fri, 3 Nov 2017 13:43:28 +0000

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:[email-masked]]
Sent: Thursday, November 2, 2017 1:36 PM
To: Black, David <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>
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

      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:

       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).

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

       in Section 4.2 below.

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

       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:

       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

       use ECN.
SUGGESTED:

       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

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

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

CURRENT:

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

       [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:

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

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

       [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>].

[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

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:

   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

       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

       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.

[David>] ACK

4.1 Congestion Response Differences

CURRENT:

   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:

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

   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:

   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:

   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

Thanks, --David

To: Black, David <[email-masked]><mailto:[email-masked]>

Hi, David,

Thanks, --David

Hi, David,

Just let me know!

Spencer

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 4 Nov 2017 00:37:50 +0000

David,

No comment = agreement.
Otherwise, see responses inline...

And you have my continuing gratitude that you're in the firing line on 
this one, not me.

On 03/11/17 13:43, Black, David wrote:
>
> 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:[email-masked]]
> *Sent:* Thursday, November 2, 2017 1:36 PM
> *Cc:* tsvwg IETF list <[email-masked]>
> 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
>
> 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./*
>
[BB] Nah, still as hard to parse. What about just deleting "changes"?

> */[David>] ACK: “This” -> “These changes”/*
>
>
> *Congestion Marking Differences:
> *CURRENT:
> */[David>] Ok, original text was courtesy of sender congestion 
> response being the focus in discussion./*
>
>
> *2.2.  Considerations for Other Protocols
> *
> */[David>] This is getting wordy.  Perhaps “Network Considerations for 
> ECN Experimentation” and then make “not involved” clearer in the body 
> of the section./*
>
[BB] Having read your responses below about each guideline in this 
section, I now remember that, as a convenience to developers of network 
equipment, you intended to collect together those aspects that affect them.

The section heading and introductory para don't say that. So if that's 
what you intend, they need to say that.

I think the desire for this section was triggered by {Sue Hares's | 
your} concern that trill-ecn-support required expertise to write in a 
way that navigated around the experiments. That led to the idea that we 
should codify that expertise into this process draft in case someone 
wants to introduce another new protocol that interacts with ECN while 
the experiments are in progress. Hmmm. IMO, protocol design guidance is 
only worthwhile when it's very narrowly scoped.

Whatever, I don't want to hold up this draft, so pls go ahead. We just 
have to tick the boxes...

>
> 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./*
>
[BB] OK

> 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:*//*
>
> */[David>] It’s more than hosts, as routers can originate traffic for 
> purposes such as control and management./*
[BB] 'A node not involved in experiments' would be fine. My main concern 
was to add the 'not involved in experiments' phrase.

> */[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./*
[BB] Oh. I didn't read into what you'd written any implication that it's 
more OK to drop CE packets than others. Where does any RFC say that? 
This is not written in RFC3168, and I'm not sure anyone shares this 
presumption.

If I am right that dropping CE packets is not a valid case, is there any 
other action of a network node for which Guideline #2 is correct?

It's not true for marking. Because network nodes not involved in an 
experiment mark ECT(0) and ECT(1) as equivalent to drop (as per Section 
4.2).

it /is/ true wrt the congestion response to markings of a sender 
involved in experiments. But you want this section to be about network 
nodes. So I cannot think of another network-based action for which 
guideline#2 is applicable.

> */[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:
>
> */[David>] That helps, I will make that change./*
>
>
> */[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
> *
> <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-07#appendix-A>  of RFC 5706*//*
> */[David>] ACK, will do./*
>
>
> 2.4
>
> CURRENT:
>
> */[David>] Will do, with “assigns” -> “assigned”/*
>
>
>
> CURRENT:
>
> */[David>] Hmm – I think that 2^nd 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./*
>
[BB] I disagree (strongly). The 2nd para is about the sender introducing 
CE randomly as an alternative to the nonce. We want to keep that 
approach - it's useful.

Perhaps you are concerned that the last sentence says random CE would be 
less effective than the nonce.

But it's OK to say that; it's actually true. Saying that doesn't 
undermine our decision to obsolete the nonce, which we justified on 
wider considerations than just effectiveness:
a) burning a codepoint for improved effectiveness isn't considered 
worthwhile any more
b) particularly because the nonce wasn't deployed.

> *//*
> */[David>] ACK/*
> *4.1 Congestion Response Differences
> *
> CURRENT:
>
> 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).
> */[David>] That doesn’t vitiate the “higher likelihood” language.  No 
> change needed here./*
>

[BB] No. The higher likelihood phrasing is incorrect.
I realized this when Ben Campbell asked "Is it a high chance of shorter 
queue, or higher chance of a short queue?"
It's neither. It's *certainty* of a short queue, but not necessarily a 
short*er* queue.

Firstly a picky point; ABE doesn't know if it's "a packet drop that 
indicates congestion".
But my argument is much bigger than that. I'll state it more precisely...

Consider ABE experiences an ECN-mark, which must be from an ECN-capable 
AQM.
I'll define the queue length in this case as Qe

Now compare with the queue lengths in these 4 cases where the same 
ECN-capable packet from ABE experiences a drop instead:
Qe = Qa : drop from non-ECN AQM
Qe < Qb : tail drop
Qe > Qc : drop from a rate policer
Qe >or< Qd : drop due to corruption

So, in no way does CE communicate that there is a higher likelihood that 
Qe is shorter in comparison to the queue had the ECN-mark been a drop 
(Qa, Qb, Qc or Qd).

Something along the lines of the alternative phrasing I suggested 
previously would be sufficient to justify ABE, without being incorrect.

> *//*
>
>
>
> *4.2 Congestion Marking Differences
> *
> CURRENT:
>
> */[David>] Ok, but use of “would” is too weak – I will split sentence 
> and make it clear that the different congestion response is necessary./*
>
[BB] Fine.

Cheers

Bob
> *//*
>     Well, I’m pleasantly surprised that Benoit cleared his Discuss
>     with a simple note of thanks and no further text change requests.
>
>     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.
>
>     *To:* Black, David <[email-masked]> <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     On Sat, Oct 21, 2017 at 12:37 PM, Black, David
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         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.
>
>         >       Filename        :