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

[Bob Briscoe <[e-mail]>]

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:
>
> 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]>
> *Cc:* [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
>     <http://www.ietf.org/shadow.html>
>     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>