Subject: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Sep 2017 16:51:11 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-tsvwg-ecn-experimentation-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Having a document which is sort of a verbal patch on another document is pretty
hard to read. I recognize that this seems to be customary in some areas, so I'm
not marking this as DISCUSS, but I really wish you would do a bis instead.

INLINE COMMENTS
Line 98
   This memo updates RFC 3168 [RFC3168] which specifies Explicit
   Congestion Notification (ECN) as a replacement for packet drops as
   indicators of network congestion.  It relaxes restrictions in RFC
Replacement or additional indicator?

Line 164
      that for congestion indicated by ECN, a different sender
      congestion response (e.g., reduce the response so that the sender
      backs off by a smaller amount) may be appropriate by comparison to
nit: reducing

Line 170
      couples the backoff change to Congestion Marking Differences
      changes (next bullet).  This is at variance with RFC 3168's
      requirement that a sender's congestion control response to ECN
I'm having a lot of trouble reading this sentence. It seems like you are
comparing the ECN response to a lost response, but these other two drafts also
are about a less aggressive response. Perhaps this would be clearer as:

"indicated by loss. Two examples of such a reduced response are..."

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 25 Sep 2017 21:08:25 +0800

Hi, Eric,

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

I'll let the author and shepherd field the INLINE COMMENTS, but I should
respond to your high-order bit as the AD.

For this draft, the key point is telling implementers "don't even think
about touching ECT(1) unless you're participating in an experiment on
ECT(1)".

After discussion about Brian Carpenter's Gen-ART review, which included the
point you raised about clarity, I think we agreed that the key point was
clear enough (and Brian thanked us for making changes based on his Last
Call review, so we are sensitive to this concern).

We have at least two experiments queued up now (L4S and TCP with
Alternative Backoff), and we may have more. The transport community has
been waiting for years to be able to use one of the ECT codepoints for
experiments, and I'd prefer not to hold them up for an ECN -bis now.

But I agree that this is spaghetti, because it is a patch on another
document, and I would support an ECN -bis at some point.

(It's possible that we'll do enough thinking about ECN when we're adding
ECN support in QUIC that an ECN -bis will look like a really good idea at
that point)

And thanks for raising this topic.

Spencer

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 26 Sep 2017 21:14:36 +0200

Hi Ekr,

what Spencer was saying between the lines was that a bis would need to 
include much more changes and would take much longer because here is 
basically a whole list that would need to be fixed. We discussed that in the 
group but would like to get out these changes needed for the experiments 
quickly and eventually make a real bis at a later point of time.

Mirja

On 25.09.2017 15:08, Spencer Dawkins at IETF wrote:
> Hi, Eric,
> 
> On Mon, Sep 25, 2017 at 7:51 AM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/>
> 
> 
> 
> For this draft, the key point is telling implementers "don't even think about 
> touching ECT(1) unless you're participating in an experiment on ECT(1)".
> 
> clear enough (and Brian thanked us for making changes based on his Last Call 
> review, so we are sensitive to this concern).
> 
> We have at least two experiments queued up now (L4S and TCP with Alternative 
> Backoff), and we may have more. The transport community has been waiting for 
> years to be able to use one of the ECT codepoints for experiments, and I'd 
> prefer not to hold them up for an ECN -bis now.
> 
> (It's possible that we'll do enough thinking about ECN when we're adding ECN 
> support in QUIC that an ECN -bis will look like a really good idea at that point)
>