Subject: [tcpm] ECN++: addressed your reviews? draft-ietf-tcpm-generalized-ecn-01

From: Bob Briscoe <[email-masked]>
Date: Fri, 29 Sep 2017 18:19:07 +0100

Padma, Gorry,

Now that ECN++ has been adopted as TCPM work, we posted
* draft-ietf-tcpm-generalized-ecn-00 (10 days ago) without any changes 
other than filename.
* draft-ietf-tcpm-generalized-ecn-01 (just now) to address your review 
concerns (actually mostly written last July)

Can you check whether -01 is OK?

We (the co-authors) have discussed how to deal with the congestion 
response to CE on Pure ACKs. We want to put our ideas to the list before 
committing to new text. So we have just tagged the Pure ACK section with 
a ToDo note for now.

Here's an overview of the changes (or you can use the links to Diffs at 
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-01 ).

*Changes that one or both of you requested:**
*
* switches -> network elements (e.g. routers, switches)
* Improved overview at the end of the Intro about where this doc sits in 
relation to other latency-related TCP drafts and RFCs (e.g. AccECN, 
ecn-experimentation, TFO, IW10, L4S)
* Motivation: Made it clear that the DCTCP scenario is not for the 
public Internet
* Clarified that ECN++ deployment needs no network changes
* Added "Mobile hosts MAY maintain
                 a cache entry per access network to record lack of 
AccECN support by
                 proxies (see Section 4.2.1)."
   and described an example mechanism in 4.2.1.
* Explained relationship between congestion response to CE on window 
probes and Congestion Window Validation (New CWV)
* Added "Fall-back measures for blockage of ECT on other TCP control 
packets
                 MAY be implemented.  However they are not specified 
here given the
                 lack of any evidence they will be needed.  [The new] 
Section 4.9 justifies this
                 advice in more detail."
* Altered discussion of ECN in SCTP to make it just one in a list of 
examples of TCP-derivative transports (including QUIC) that could adopt 
a similar approach to the ECN++ experiment in TCP.
* Cited appropriate QUIC refs.

*Changes that we initiated:**
*
* Stated that this EXP doc obsoletes RFC5562 (which is also EXP), and 
added 5562 to the "Obsoletes:" header.
* More focused "MEASUREMENT NEEDED" text in places
* If no response following ECT on SYN or SYN-ACK, "SHOULD" only 
fall-back after 2 attempts (was 1, but experiments show no evidence of 
middlebox interference, so loss will more likely be due to other causes 
like congestion or radio interference).
* Added client-based alternative to server-based caching of failed 
connection attempts with ECT set (Section 4.3.2)
* General improvements for clarity
* Updated refs
* Changed Bob's affiliation to CableLabs

Cheers

Bob & Marcelo