[tcpm] Comments on draft-ietf-tcpm-accurate-ecn-14

[Gorry Fairhurst <[e-mail]>]

Abstract:
/Given TCP header
    space is scarce, this allocates a reserved header bit, that was
    previously used for the ECN-Nonce which has now been declared
    historic. /
- English: /which/that/ /that/which/ perhaps??
- However, I wonder if this is necessary in the abstract, surely a 
reader of the abstract in future would only need to know:
/This allocates a reserved header bit, previously used for the ECN-Nonce./

I also do wonder if the abstract still rather complicated (aka long)?
——
Section 2.5:
/According to [RFC3168] the Data Sender is meant to
    set control packets to Not-ECT.  However, mechanisms in certain
    private networks (e.g. data centres) set control packets to be ECN
    capable because they are precisely the packets that performance
    depends on most./
- I think /set/ is rather odd.
- Can we talk about the /ECN IP field/ being set (as used later) ?
——
Two questions in the same sentence on p16, starting /So, without these 
rules/:
/could end up/
- this seems possibly one of those phrases that confuses non-native 
speakers?

/using difference feedback modes/
- is that word really difference not different?

——

Section 3.2
/3.3.2.  Requirements for TCP Normalizers/

I like the introduction of subheadings within 3.2, because it helps 
people find the part of the spec they need to see - especially important 
when the implementer only needs to understand one aspect in detail, 
however, I wonder if this second part needs a separate heading:
/A middlebox claiming to be transparent/
… really only for normalisers? - I expected this to be relevant to any 
“transparent” middlebox”
- would it be better with a separate subsection for this important point?
—
I have re-read /3.3.3. Requirements for TCP ACK Filtering/ in -14, and 
although I am not yet sure of the speculation that using ECN in future 
is sufficient to regulate the ratio of ACKs to Data, I believe the text 
is correct in its interpretation of RFC3449, and that the present design 
is anyway robust to ACK mitigation methods.
——
/Once DCTCP offload hardware supports AccECN/
… I’m not sure this para is perfected yet, because it is directed at 
DCTCP. I’d like to consider a reordering that is more like:

/The above process has been designed to enable a continuing
  incremental deployment path - to more highly dynamic congestion
  control.  Once offload hardware supports AccECN, it will be
able to coalesce efficiently for any sequence of marks, instead of
  relying for efficiency on the long marking sequences from step
  marking.  In the next stage, marking can evolve from a step to
a ramp function.  That in turn will allow host congestion control
algorithms to respond faster to dynamics, while being backwards
compatible with existing host algorithms./
… i.e., do we really have to directly discuss DCTCP here, doesn’t it in 
general refer to AccECN rather?
——

Security Considerations:

The “downgrade attack” regarding a receiver deciding/accidentally 
omitting an option in the Security Considerations seems incorrect to me.
To me, the text is written in a way that sounds like it impacts the 
“security” of the connection. I do not agree with that interpretation. 
To me, this is a performance reduction, and the degrade does not impact 
the ability to communicate or security properties. I suggest some 
rewording here.
——
Security Considerations:

There’s now also a Security Considerations include a ToDo, that I do not 
yet understand, look forward to this!
——

Best wishes,

Gorry

(P.S. I will send one more specific question in a separate email).