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

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

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

Thanks, --David

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

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 <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]<mailto:[e-mail]>]
Sent: Monday, August 7, 2017 2:37 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-04.txt

Hi, David,

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <[e-mail]<mailto:[e-mail]>> 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 ...").
[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,

   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?
[David>] This has been brought up too many times in WG discussion of this draft to leave out, IMHO.

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

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.

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

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

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

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


> -----Original Message-----
> From: tsvwg [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of internet-
> [e-mail]<mailto:[e-mail]>
> Sent: Friday, August 4, 2017 7:29 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.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           : 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<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/