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

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

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

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


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