Skip to main content

Early Review of draft-ietf-tcpm-accurate-ecn-30
review-ietf-tcpm-accurate-ecn-30-intdir-early-touch-2024-08-30-00

Request Review of draft-ietf-tcpm-accurate-ecn-30
Requested revision 30 (document currently at 30)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2024-09-02
Requested 2024-08-19
Requested by Michael Tüxen
Authors Bob Briscoe , Mirja Kühlewind , Richard Scheffenegger
I-D last updated 2024-08-30
Completed reviews Secdir Early review of -14 by Scott G. Kelly (diff)
Intdir Early review of -30 by Dr. Joseph D. Touch
Secdir Early review of -30 by Scott G. Kelly
Comments
This document is now almost ready. It is now under review of the responsible AD.
It would be great if the reviewers have some familiarity with TCP.
For the sec review, this was suggested by the earlier sec reviewer.
For the int review, looking at middlebox interactions would be much appreciated.
Assignment Reviewer Dr. Joseph D. Touch
State Completed
Request Early review on draft-ietf-tcpm-accurate-ecn by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/V_haR3271qzmh-v_mrxp2hmqa2E
Reviewed revision 30
Result Ready w/issues
Completed 2024-08-30
review-ietf-tcpm-accurate-ecn-30-intdir-early-touch-2024-08-30-00
From an INTAREA perspective, this document has no concerns.

However, viewed from a transport perspective, the document has one key concern
- the use of two TCP code points. Information expressed in TCP options should
occur inside the option payload, not be encoded indirectly in code points. The
variants desired in Table 5 can easily be differentiated using a single bit of
the first counter indicated. There's no good reason to consume two TCP code
points for this optimization.

Additionally and somewhat less significantly, it is nonsensical to assign
non-adjacent code points, again as this unnecessarily breaks up the TCP code
point space for use by other future assignments (e.g., were there to be a
legitimate need for a range of code points). Frankly, see no good reason why
this mechanism should not use code points in order of availability, e.g., 80
(and, with GREAT hesitation, 81 if warranted).