[tcpm] Comments on ECN++ (rev 02)

[Gorry Fairhurst <[e-mail]>]

[e-mail]

I reviewed this draft prior to the IETF-100 meeting, but did not manage 
to send notes until just now. Thanks for this revison!

Overall, I had three observations and some comments on the writing iof 
the current ID.

* It seems like a silly question, but as I read this I do wonder: Do we 
**need** to allow ECT(1) on SYN as in 3.2.2.1?

* I think the AccECN studff requires a decision on how to present the 
info differently. This talks about recommending AccECN implementation, 
which implies a reader beds ti read both this and AccECN together. Both 
of these are long documents, and when you read these together one 
discovers many areas of overlap - but the pieces neded are in both drafts.

... One thing I suggest we consider is whether the ECN++ draft simply 
defines the method when AccECN is not supported. The AccECN draft 
appears to contain the machinery to allow ECT on SYN. One drawback is 
that the AccECN draft does not define mechanisms to react, but does 
define fallback. It could even be that the simplest is to write 3 drafts 
- having one just on AccECN+ECTonSYN?

... The considerations for reaction to CE-marked SYN and the 
implications of loss seem to be one area of experimentation, hence 
placing this in one place may help identify whether that experiment has 
suceeded. I'll type-up my notes on AccECN next.

Whatever, the two drafts are not consistent on the use of caching, and 
specifying the SYN processing once I think would help to simplify things.

If this is the direction, Table 1 could then be simplified, and one 
could add a column showing the section number where the topic is discussed?

* The section 4 is quite long. I'm not sure of who is the real target 
(or tragets) for section 4 and I think this therefore needs to be made 
clearer, so that people would know beforehand whether they should read 
the whole of this section.

Gorry

---

Some more specific comments on the text in the -02 draft:

(1) Style: The introduction sectionc contains a "RECOMMENDS: statement 
recommending AccECN. This comes before the IETF keyword declaration, and 
is not normal for an introduction. I suggest you avoid keywords in the 
intro.

(2) Final para of 1.1
- I really dislike the way this statemnent somehow reads as asserting 
the value of "ongoing experimental efforts to promote the adoption of a 
***slightly*** modified variant of DCTP". I suggest the should be 
English improved here, to avoid making the prior claim that this is 
"slight" (even if it may turn out to be so).  e.g., if the WG thinks the 
work should be based on DCTP, I'm sure the ID can say ths, but I'd 
really prefer we simply state the effort to build an IETF transport for L4S.

(3)Final para of 1.1: Is there really a problem with the SYN packet 
travelling via a different queue? The text suggests reordering is an 
issue, which I do not understand.  I'd have thought a SYN packet was the 
only packet in flight when the connection is being setup, what is the 
ordering wrt?

(4) I think in this case you could refer to the RFC: There is a phrase 
/When this specification/. This phrase always seems problematic in ID, 
with ambiguity to know whether it refers to the present document.

(5) TEXT: "MAY be adopted if found to be more effective".
- To me that seems like the document is almost defining working group 
process surrounding this. I don't think this document ought to do this. 
I suggest you delete the text, or at least don't use a RFC2119 keyword.

(6) TEXT: "MAY also implement AckCC".
-  Is this a /It is RECOMMENDED that AckCC is implemented/ - from text 
elsewhere this seems correct. I think some people prefer to say "is 
RECOMMNDED" when the text refers to an implemementation requirement, 
rather than protocol requirement.

(7) 3.2.3
- I do see the logic in not setting ECT unless there is feedback 
sup[ported to report CE.

(8) 3.2.4
- Please rephrase the first para in terms of citing the ECN-Experiments 
ID (in TSVWG) that enables this, rather than talking of the prohibition 
that has passed and the need to ignore - there is no need for this, 
since the TSVWG ID *WILL* be published before this.

(9) 3.2.6
- This recommends RFC5961. This seems an odd thing to suddently place an 
implementation requirement, if there are important requirements then I 
would hope these appear earlier in the document and are justified. I 
really encourage the WG to put all implementation requirements in a 
separate section, so implementors know what depends on what.

(10) Setion 4
- The section seems to call out a number of things that need to be done. 
Some of these may be neded before WGLC... but I don't know see which? 
Some are evidently targeting IETF experimentation, some are discussion 
of the background (could be an appendix?). At the moment this makes for 
quite a long read.

(11) Section 5.3, Para 1
The style of the SCTP discussion seems well-intentioned, but 
inappropriate, since it is based on a long-expired draft. (I strongly 
suggest we do not publish RFCs that discuss IDs that have not been 
progressed in WGs.) I suggest that more appropriate text could simply 
say "RFC4960 describes how ECN would be supported for SCTP, but at the 
time of writing there is no IETF Specification for this", or something 
similar.

Gorry