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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, David,

On Wed, Aug 30, 2017 at 11:09 AM, Black, David <[e-mail]> wrote:

> 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?" ;-)


> 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]>
> 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]]
> *Sent:* Monday, August 7, 2017 2:37 PM
> *To:* Black, David <[e-mail]>
> *Cc:* [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]> 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]] On Behalf Of internet-
> > [e-mail]
> > Sent: Friday, August 4, 2017 7:29 PM
> > To: [e-mail]
> > Cc: [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.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
>
>
>
>
>