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

From: [email-masked]
Date: Fri, 04 Aug 2017 16:28:51 -0700

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           : Explicit Congestion Notification (ECN) Experimentation
        Author          : David Black
	Filename        : draft-ietf-tsvwg-ecn-experimentation-04.txt
	Pages           : 17
	Date            : 2017-08-04

Abstract:
   This memo updates RFC 3168, which specifies Explicit Congestion
   Notification (ECN) as a replacement for packet drops as indicators of
   network congestion.  It relaxes restrictions in RFC 3168 that would
   otherwise 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 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-04
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Black, David" <[email-masked]>
Date: Fri, 4 Aug 2017 23:31:56 +0000

As discussed in Prague, this is a small update to request that IANA remove the registration of the TCP header flag used by RFC 3540 (ECN Nonce).   Any reassignment of that flag will be handled by the TCPM WG.  This update also changes the name of one of the areas of ECN experimentation to be different from the name of the experiment proposed in that area.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Friday, August 4, 2017 7:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Aug 2017 13:36:45 -0500

Hi, David,

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <[email-masked]> wrote:

> As discussed in Prague, this is a small update to request that IANA remove
> the registration of the TCP header flag used by RFC 3540 (ECN Nonce).   Any
> reassignment of that flag will be handled by the TCPM WG.  This update also
> changes the name of one of the areas of ECN experimentation to be different
> from the name of the experiment proposed in that area.
>
> Thanks, --David
>

Hi, David,

I really like this draft. Thanks to you and your ACK list for your efforts
- the result is very clear and complete.

I have a few questions before I push the button on Last Call. They're minor
enough that I don't think we need to wait for Gorry to be present for the
discussion (of course, if people disagree, just let me know).

I tried to offer text for most of them, but you might also answer them by
saying that TSVWG needs a much smarter responsible AD ;-) ...

In this text,

   An Experimental RFC MUST be published for any protocol
   or mechanism that takes advantage of any of these enabling updates.

I think I know what you're saying, but this formulation confuses me because
it's placing a commitment on what a future working group must do (like,
what if the draft describing the experimental protocol is incoherent - can
the working group Just Say No, or can the authors say "but you have to
request publication, because "An Experimental RFC MUST be published ...").

Is your point that any protocol or mechanism that takes advantage of these
enabling updates can't be Standards-Track?

In this text,

   There is no need to make changes for protocols and mechanisms that
   are documented in Standards Track RFCs, as any Standards Track RFC
   can update RFC 3168 without needing a standards process exception.

we've been talking using this terminology for at least a year that I can
remember, but I'm not totally sure that an average IESG would even approve
an Experimental draft that updated a standards-track RFC. How badly do you
need to say this at all, since you're just confirming a well-understood
fact that I think we all agree on?

In this text,

   A study of the ECN behaviour of the Alexa top 1M web
   servers using 2014 data [Trammell15]

I'm wondering whether it's useful to say "Alexa top 1M web servers" in an
RFC that will probably last longer than Alexa lasts ...

In this text,

   Significantly more aggressive sender responses to ECN
   are required to make effective use of such shallow queues; Datacenter
       ^^^^^^^^
   TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example.

I'm tangled up in passive tense ("who is required to do what?"). Is it
correct to say

   Significantly more aggressive sender responses to ECN
   are needed in order to make effective use of such shallow queues;
   Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example.

?

I see that the draft uses both the terms "shallow queues" and "nearly empty
queues". Do these terms mean the same thing? If so, perhaps it's worth
either picking one term, or saying that they mean the same thing. Right
now, I'm trying to imagine what the difference might be, since both phrases
are used.

You folks are the experts on this stuff, but I'm looking at this quoted
text from RFC 3168

 RFC 3168 prohibits use of ECN for TCP control packets and
   retransmitted packets in a number of places:

   o  "To ensure the reliable delivery of the congestion indication of
      the CE codepoint, an ECT codepoint MUST NOT be set in a packet
      unless the loss of that packet in the network would be detected by
      the end nodes and interpreted as an indication of congestion."
      (Section 5.2)

   o  "A host MUST NOT set ECT on SYN or SYN-ACK packets."
      (Section 6.1.1)

   o  "pure acknowledgement packets (e.g., packets that do not contain
      any accompanying data) MUST be sent with the not-ECT codepoint."
      (Section 6.1.4)

   o  "This document specifies ECN-capable TCP implementations MUST NOT
      set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for
      retransmitted data packets, and that the TCP data receiver SHOULD
      ignore the ECN field on arriving data packets that are outside of
      the receiver's current window."  (Section 6.1.5)

   o  "the TCP data sender MUST NOT set either an ECT codepoint or the
      CWR bit on window probe packets."  (Section 6.1.6)

and noticing that only the text in 6.1.5 explicitly mentions the TCP data
receiver ignoring the "MUST NOT set" ECN field. I took a quick spin through
RFC 3168 searching for "ignore", but didn't see something that explicitly
covered the other cases.

Because these are "MUST NOT set" constraints, I could imagine implementers
who never anticipated that an ECN(0) or ECN(1) would be set, and don't look
at the field (probably good), but I can also imagine implementers
validating that ECN(0) and ECN(1) are not set (probably bad). Do people
have any concerns about encountering "ECT values MUST be cleared"
implementations during this experiment?

I suppose if some implementation that does this is deployed and you folks
run the experiment, then we'll know :D ...

But I wonder if it's worth making that clear for receivers, since you're
updating RFC 3168 anyway?

In this text,

      Random ECT values MUST NOT be used, as that may expose RTP to
      differences in network treatment of traffic marked with ECT(1) and
      ECT(0) and differences in associated endpoint congestion
      responses,

is "Random ECT values" the right word? I could imagine this prohibiting
using ECT(0) and ECT(1) interchangeably, but if that's what's intended, I
could also imagine this prohibiting simply not explicitly setting the ECT
values at all, so missing your point.

I'm looking at this text

   As a process memo that makes no changes to existing protocols, there
   are no protocol security considerations.

and wondering if it's current with the rest of the document. Is "no changes
to existing protocols" still the right way to characterize this draft? If
you wanted to say

   As a process memo that only adds limitations to existing protocols, there
   are no protocol security considerations.

I'd be happy to believe you ...

Thanks,

Spencer

---

From: "Black, David" <[email-masked]>
Date: Wed, 30 Aug 2017 15:30:40 +0000

Hi Spencer,

Resurfacing from trying to take vacation in August – many thanks for this detailed review.  Comments inline.

I have a -05 ready to go if these changes are ok with you.

Thanks, --David

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Monday, August 7, 2017 2:37 PM
To: Black, David <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt

Hi, David,

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
As discussed in Prague, this is a small update to request that IANA remove the registration of the TCP header flag used by RFC 3540 (ECN Nonce).   Any reassignment of that flag will be handled by the TCPM WG.  This update also changes the name of one of the areas of ECN experimentation to be different from the name of the experiment proposed in that area.

Thanks, --David

Hi, David,

I really like this draft. Thanks to you and your ACK list for your efforts - the result is very clear and complete.

I have a few questions before I push the button on Last Call. They're minor enough that I don't think we need to wait for Gorry to be present for the discussion (of course, if people disagree, just let me know).

I tried to offer text for most of them, but you might also answer them by saying that TSVWG needs a much smarter responsible AD ;-) ...

In this text,

I think I know what you're saying, but this formulation confuses me because it's placing a commitment on what a future working group must do (like, what if the draft describing the experimental protocol is incoherent - can the working group Just Say No, or can the authors say "but you have to request publication, because "An Experimental RFC MUST be published ...").
[David>] The working group can Just Say No, and that outcome would be a “feature” – if the experimental protocol is problematic, then the experiment shouldn’t be run at scale in the Internet, and the WG will have done the right thing by saying so.

Is your point that any protocol or mechanism that takes advantage of these enabling updates can't be Standards-Track?
[David>] No – a Standards-Track protocol RFC can simply update RFC 3168 (and any other RFCs that it needs to) directly, and doesn’t need this draft’s permission to do so, as the next sentence states …

In this text,

we've been talking using this terminology for at least a year that I can remember, but I'm not totally sure that an average IESG would even approve an Experimental draft that updated a standards-track RFC. How badly do you need to say this at all, since you're just confirming a well-understood fact that I think we all agree on?
[David>] This has been brought up too many times in WG discussion of this draft to leave out, IMHO.

In this text,

I'm wondering whether it's useful to say "Alexa top 1M web servers" in an RFC that will probably last longer than Alexa lasts ...
[David>] I view this as a “show your work” item … this is the data that was used at the time.

In this text,

I'm tangled up in passive tense ("who is required to do what?"). Is it correct to say

?
   [David>] Yes, change made.

I see that the draft uses both the terms "shallow queues" and "nearly empty queues". Do these terms mean the same thing? If so, perhaps it's worth either picking one term, or saying that they mean the same thing. Right now, I'm trying to imagine what the difference might be, since both phrases are used.
[David>] Good point, changed to consistently use “very shallow” everywhere.

You folks are the experts on this stuff, but I'm looking at this quoted text from RFC 3168

and noticing that only the text in 6.1.5 explicitly mentions the TCP data receiver ignoring the "MUST NOT set" ECN field. I took a quick spin through RFC 3168 searching for "ignore", but didn't see something that explicitly covered the other cases.

Because these are "MUST NOT set" constraints, I could imagine implementers who never anticipated that an ECN(0) or ECN(1) would be set, and don't look at the field (probably good), but I can also imagine implementers validating that ECN(0) and ECN(1) are not set (probably bad). Do people have any concerns about encountering "ECT values MUST be cleared" implementations during this experiment?

I suppose if some implementation that does this is deployed and you folks run the experiment, then we'll know :D ...
[David>] I would leave this to the drafts/RFCS that describe the experiments, as I expect implementers of the experiments to look there, and not at this process RFC (to be).

But I wonder if it's worth making that clear for receivers, since you're updating RFC 3168 anyway?

In this text,

is "Random ECT values" the right word? I could imagine this prohibiting using ECT(0) and ECT(1) interchangeably, but if that's what's intended, I could also imagine this prohibiting simply not explicitly setting the ECT values at all, so missing your point.
[David>] Yes, “Random” is the right word, as the text quoted from RFC 6679 uses the word “random” so that is the correct word to use here, and further explanation can be found in RFC 6679.

I'm looking at this text

and wondering if it's current with the rest of the document. Is "no changes to existing protocols" still the right way to characterize this draft? If you wanted to say

I'd be happy to believe you ...
[David>] I see the concern, and edited the text roughly as suggested, plus moved a supporting sentence about security considerations for the experiments up to join this sentence, so the new paragraph now reads:

As a process memo that only removes limitations on proposed experiments,
there are no protocol security considerations.  Security considerations for the
proposed experiments are discussed in the Internet-Drafts that propose them.

Thanks,

Spencer

> From: tsvwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> [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>.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 30 Aug 2017 10:57:23 -0500

Hi, David,

Thanks, and welcome back :-)

This mostly looks uber-reasonable, but I have one reply on Alexa below.

On Wed, Aug 30, 2017 at 10:30 AM, Black, David <[email-masked]> wrote:

> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* Monday, August 7, 2017 2:37 PM
> *To:* Black, David <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-
> experimentation-04.txt
>
>
>
> Hi, David,
>
>
>
> I have a few questions before I push the button on Last Call. They're
> minor enough that I don't think we need to wait for Gorry to be present for
> the discussion (of course, if people disagree, just let me know).
>
>
>
> I think I know what you're saying, but this formulation confuses me
> because it's placing a commitment on what a future working group must do
> (like, what if the draft describing the experimental protocol is incoherent
> - can the working group Just Say No, or can the authors say "but you have
> to request publication, because "An Experimental RFC MUST be published
> ...").
>
> *[David>] The working group can Just Say No, and that outcome would be a
> “feature” – if the experimental protocol is problematic, then the
> experiment shouldn’t be run at scale in the Internet, and the WG will have
> done the right thing by saying so. *
>
>
>
> *[David>] No – a Standards-Track protocol RFC can simply update RFC 3168
> (and any other RFCs that it needs to) directly, and doesn’t need this
> draft’s permission to do so, as the next sentence states …*
>
>
>
> In this text,
>
>
>
> *[David>] This has been brought up too many times in WG discussion of this
> draft to leave out, IMHO.*
>
>
>
> In this text,
>
>
>
> *[David>] I view this as a “show your work” item … this is the data that
> was used at the time.*
>

I'm sorry that my comment wasn't clear. What I was asking was if there was
any more description of Alexa (or for extra credit, a URL) so that a reader
in ten years can do more than google "Alexa top 1M web server" to figure
out what this is.

So I'm wondering if you need to qualify "top 1M web servers" as "Alexa top
1M web servers", because I'm thinking adding the adjective doesn't add as
much as it takes away.

It may be that the answer is "not really", and that would be A Fine Answer,
but I wanted to make sure you understood what I was thinking, because it
apparently wasn't what I was typing :-)

Either way, I'm ready for you to send the updated version and have me
initiate Last Call, and thanks for horsing this through.

Spencer

>    *[David>] Yes, change made.*
>
>
>
> I see that the draft uses both the terms "shallow queues" and "nearly
> empty queues". Do these terms mean the same thing? If so, perhaps it's
> worth either picking one term, or saying that they mean the same thing.
> Right now, I'm trying to imagine what the difference might be, since both
> phrases are used.
>
> *[David>] Good point, changed to consistently use “very shallow”
> everywhere.*
>
>
>
> *[David>] I would leave this to the drafts/RFCS that describe the
> experiments, as I expect implementers of the experiments to look there, and
> not at this process RFC (to be).*
>
>
>
> *[David>] Yes, “Random” is the right word, as the text quoted from RFC
> 6679 uses the word “random” so that is the correct word to use here, and
> further explanation can be found in RFC 6679.*
>
>
>
> I'm looking at this text
>
>
>
> and wondering if it's current with the rest of the document. Is "no
> changes to existing protocols" still the right way to characterize this
> draft? If you wanted to say
>
>
>
> *[David>] I see the concern, and edited the text roughly as suggested,
> plus moved a supporting sentence about security considerations for the
> experiments up to join this sentence, so the new paragraph now reads:*
>
>
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 30 Aug 2017 16:09:44 +0000

Ok, I’ll drop “Alexa” and upload the result.

Thanks, --David

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Wednesday, August 30, 2017 11:57 AM
To: Black, David <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt

Hi, David,

On Wed, Aug 30, 2017 at 10:30 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

Thanks, --David

From: Spencer Dawkins at IETF [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 7, 2017 2:37 PM
To: Black, David <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt

Hi, David,

Thanks, --David

Hi, David,

In this text,

In this text,

In this text,

I'm sorry that my comment wasn't clear. What I was asking was if there was any more description of Alexa (or for extra credit, a URL) so that a reader in ten years can do more than google "Alexa top 1M web server" to figure out what this is.

So I'm wondering if you need to qualify "top 1M web servers" as "Alexa top 1M web servers", because I'm thinking adding the adjective doesn't add as much as it takes away.

It may be that the answer is "not really", and that would be A Fine Answer, but I wanted to make sure you understood what I was thinking, because it apparently wasn't what I was typing :-)

Either way, I'm ready for you to send the updated version and have me initiate Last Call, and thanks for horsing this through.

Spencer

In this text,

?

In this text,

I'm looking at this text

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 30 Aug 2017 11:34:33 -0500

Hi, David,

> Ok, I’ll drop “Alexa” and upload the result.

Thanks!

Spencer, who was visualizing someone thinking "Alexa Morris has a 'top 1M
websites'? Who knew?" ;-)

> *Sent:* Wednesday, August 30, 2017 11:57 AM
>
> It may be that the answer is "not really", and that would be A Fine
> Answer, but I wanted to make sure you understood what I was thinking,
> because it apparently wasn't what I was typing :-)
>
>
>