Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-tcpm-accurate-ecn-32 Reviewer: Elwyn Davies Review Date: 2025-02-16 IETF LC End Date: 2025-02-10 IESG Telechat date: 2025-02-20 Summary: This specification is mind-blowingly complex and I have no idea whether it is technically self-consistent or whether it would actually deliver the specified aims. As far as I can see it is well written and clearly can be implemented. There are some nits that should be sorted out and some minor layout improvements are desirable. The main issue I would have is that I am not really sure what parts need to be implemented to deliver the 'essential feedback' basic option, or indeed whether such a partial implementation would be relevant as opposed to it being what happens if badly implemented or intrusive middleboxes get in the way and the behavious defaults to the essentials. There are a number of abbreviations that might be better combined into the Terminology section with the existing pieces rather than being defined in line... it is inconsistent. Aside: I am amused that some 25 years on from when I started work in the IETF, I am reviewing a document that is a new version of ones that were being worked on back then - DiffServ and the original congestion notification! Major issues: None Minor issues: s2: I am not sure that I could definitely assure myself that I knew which parts of the specification were required to deliver the 'essential (feedback) part' and what was only needed for the supplementary part. Section 6 has some comments but I am not sure that it will truly help. s2.3, para 3: Where can one find the analysis that backs up the assertion of needing an infeasibly long sequence of ACK losses? Nits/editorial comments: Global: s/e.g. /e.g., /g (25 places), s/i.e. /i.e., /g (3 places) PS Not sure you should use I.e. to start a sentence (s3.2.2.1). Abstract and s1: The term 3-way handshake is a well known term of art referring to TCP connection setup but it needs a reference for the less well aware. I note that RFC 9293 uses the form three-way handshake rather than 3-way handshake - this document uses the two forms inconsistently. Thus: In Abstract: OLD: exploited to feed back the IP-ECN field received during the 3-way handshake as well. NEW: additionally exploited to feed back the IP-ECN field received during the three-way handshake that is used to establish a TCP connection as described in RFC 9293 and RFC 3168. END In s1.3: The term 3-way/three-way handshake ought to be included in the Terminology section (s1.3) In s3.2.2.3, the abbreviation 3WHS is introduced as am abbreviation for 'three-way handshake' and used a further 4 times. The abbreviation should be defined in s1.3. In s1.4, the usage of ECN or otherwise is negotiated during connection set up as part of the 3-wqy handshake. I suggest modifying the start of para 2: OLD: Once ECN has been negotiated for a transport layer connection, NEW: Once ECN has been negotiated for a transport layer connection using the three-way connection establishment protocol, Title of s3.1.1 and beginning of s3.1.1, para 2: s/TCP handshake/TCP three-way handshake/ ****** End of stuff about 3-way handshake Reason and Reasoning items: I suggest that the document should use one of these terms throughout for consistency. In the majority of cases, the reason(ing) is separated from the normative instructions into a separate paragraph. I think this is a good idea and would be good to apply it to all cases. It might also be sensible to use the XML quoted paragraph format for the reasoning paragraphs to distinguish them from the normative text. In s1. para 1, next to last sentence: s/as dast as/as fast as/ In s1, para 2; definition of AccECN in s1.3; s2, third bullet of second set of bullets; and s8, last sentence: Maybe (for consistency with Classic ECN feedback) s/accurate ECN feedback/Accurate ECN feedback/. Linked to this, s8, last sentence: s/classic ECN/Classic ECN/ (all the other cases are right!) Starting in s2: To avoid any possible ambiguity, I suggest using 'essential feedback' and 'supplementary feedback' to to refer to the two AccECN use cases described in the two bullet points in s2. There are five places where essential is used (one does not need modification) and four where supplementary is used where it would be helpful to expand the name. s2, para 4 (second bullet): s/rationale for/rationale determining that/, s/is preferred over/should be preferred over/ s2.2, para 1: s/excluding the TCP header or TCP options./excluding the TCP header and TCP options./ (I think) s2.2, last sentence: s/in opposite order/in the opposite order/ s3.1.1, para 2: s/TCP Server (B)/TCP Server (host B)/ for clarity after TCP Client (host A) s3.1.1, last para: SACK and DSACK need to be expanded. Table 2: suggest labelling first two columns Host A and Host B. s3.1.5 contains: * Any implementation that supports AccECN: ........... - SHOULD ignore the TCP-ECN flags in SYNs or SYN/ACKs that are received after the implementation reaches the Established state, in line with the general TCP approach [RFC9293]; What might it do if it decides not to ignore this case? s3.2.2.1, Note 3: s/spec/document/ s3.2.2.4, para 3: This piece would be clearer with the 'reason' separated out and the three items mentioned set out as a numbered list. s3.2.2.4, para 5: I take it that 'the first packet... that arrives' refers to the wording in para 3 of this section. but it does not duplicate the partial wording in para 3 precisely. A more definite connection and/or accurate wording is needed. s3.2.2.5.1, para 7: Need to expand AQM (Active Queue Management I assume). s3.2.2.5.1, last para: s/spec/specification/ (2 places) -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
