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

From: "Black, David" <[email-masked]>
Date: Tue, 17 Oct 2017 19:08:55 +0000

Ekr,

Thanks for the careful review.  Edits described inline below are in a working version of what will become the -07 version.

Thanks, --David

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Sunday, September 24, 2017 7:51 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Gorry Fairhurst
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Eric Rescorla's No Objection on draft-ietf-tsvwg-ecn-
> experimentation-06: (with COMMENT)
> 
> 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.
> 
[David>] In addition to Mirja's response, I'd add that a better time to do a 3168bis would be after we understand the results of the experiments so that the bis can roll the successful results up into a single document.

> 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?
> 
[David>] The latter - new text"  "... as an alternative to packet drops for indicating network congestion to endpoints."  Change made both here and in abstract.

> 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
> 
[David>] Removed "reduce the response so that the" as unneeded verbiage, both here and in Section 4.1.

> 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..."
> 
[David>] Broke into two sentences as suggested, second sentence starts with "Two examples of proposed sender congestion response changes are described in ...