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

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

Update:
- Issue [A] was closed in this email thread.
- Bob and I are close to off-list agreement on text for issues [B] and [E] (text will be sent to the list, once we agree).
- Off-list text agreement on issue [D] will hopefully follow text agreement on issues [B] and [E].
That leaves issue [C]  …

The text in my working draft of -08 for [C] (guideline in Section 2.2) is:

   2.  Network nodes that forward packets 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 below).  This is
       already the case when the ECN field is used for Pre-Congestion
       Notification (PCN) [RFC6660].

A significant factor appears to be that there is no text describing the potential bad consequences of ignoring the “SHOULD NOT” guideline.

Here’s an attempt at rephrasing to address that:

   2.  Network nodes that forward packets SHOULD NOT assume that the ECN
       CE codepoint indicates that the packet would have been dropped if
       ECN were not in use.  This is because Congestion Marking Differences
       experiments employ different congestion responses to dropped packets
       by comparison to receipt of CE-marked packets (see Section 4.2 below),
       so CE-marked packets SHOULD NOT be arbitrarily dropped.  A corresponding
       difference in congestion responses already occurs when the ECN field is
       used for Pre-Congestion Notification (PCN) [RFC6660].

Thanks, --David

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

David,
On 07/11/17 02:56, Black, David wrote:
Bob,

First of all, thanks for the response, as it represents visible progress.  I’m copying message thread text for only the 5 topics where we have a disagreement. TL;DR summary:

[A] This is an editorial nit – I suggest letting this one go.
[BB] OK

[B] It looks like we mostly agree on the goal – I need to send you some detailed text to capture that offline.
[BB] The intended scope of this new section is still stated in 2 contradictory ways. We're resolving that offlist.

[C] Open issue, but seems relatively minor – let’s continue discussion here towards resolving this.
[BB] My concern with this bullet is that it tries to stop a behaviour that you think people might believe was implied by RFC3168, without describing this hypothetical behaviour that probably no-one had thought of doing anyway.


[D] I’m ok with the request (don’t delete a paragraph from RFC 3168), but to balance out [B] ;-), you need to send me some detailed text, as the paragraph cannot remain as-is.
[BB] OK, I see now that para 2 doesn't stand alone if solely para 1 is deleted. I'll provide suggested text (initially off list).


[E] There’s a small word change that might resolve this issue, otherwise, the underlying concern with the ABE draft will need to be worked out at the TCPM meeting in Singapore.
[BB] I'm OK with the small word change, which I thought had been requested during the IESG review anyway. But once you make the small word change, the rest of the sentence doesn't make sense, which is what I was trying to fix.



Spencer – item [E] suggests that there may not be a revised -08 version of this draft until after TCPM meeting in Singapore.
Like you, I'm travelling on Thu. So I think we should be able to get this fixed so you can post -08 before/during Singapore.

Cheers



Bob




--[A]--

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.
[BB] Nah, still as hard to parse. What about just deleting "changes"?


David> I think the capitalization sorts out this entirely editorial concern.

--[B]--

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

David> The motivation is more about protocol design guidance, e.g., for the trill-ecn-support draft, than about network equipment implementation guidance.   I think we’re mostly aligned, as I agree in principle with the final paragraph quoted above.  Let me see if I can work out some text off-line directly with you.

--[C]--


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


David> Well, here’s RFC 3168, section 6.1.2 on TCP Sender behavior: “The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP.”  While that was written as a lower-case “should” in RFC 3168, in practice, it was treated as an upper case “MUST” in implementations at the time.  My concern that it’s a short mental distance from there to thinking that it’s ok to drop CE packets because the transport protocol reaction will be the same.  The warning that CE is not drop equivalent is intended to stop that sort of “slippery slope” thinking.

--[D] --

2.4

David> This is actually in Section 3, not 2.4.

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


David> I’m willing to keep some form of the text, but the paragraph in its current form refers to the ECN nonce, all mention of which is being removed from RFC 3168.
**Please send me (off-list) the *precise* text that you want to use to turn this into a stand-alone paragraph that does not refer to the ECN nonce.**

--[E] --

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.

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


David>  I’m willing to change “shorter” to “short” if that resolves this issue.
David> Otherwise, we have a problem with this text in the abstract of the TCPM ABE draft (draft-ietf-tcpm-alternativebackoff-ecn-03):

   An Explicit Congestion Notification (ECN)
   signal indicates that an AQM mechanism is used at the bottleneck, and
   therefore the bottleneck network queue is likely to be short.

David> See the last paragraph in section 2 of that draft for supporting discussion.

David> I also see a number of problems with the attempt to prove “certainty” of a short queue but I’ll save them for the TCPM meeting in Singapore, which is where this issue should be dealt with if the assertion is that the above statement from the AQM draft is erroneous.

Thanks, --David

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

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:[e-mail]]
Sent: Thursday, November 2, 2017 1:36 PM
To: Black, David <[e-mail]><mailto:[e-mail]>
Cc: tsvwg IETF list <[e-mail]><mailto:[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.
[BB] Nah, still as hard to parse. What about just deleting "changes"?




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




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.
[BB] 'A node not involved in experiments' would be fine. My main concern was to add the 'not involved in experiments' phrase.





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





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





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

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

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

Cheers




Bob







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