[tcpm] Review of draft-ietf-tcpm-accurate-ecn-28

[Martin Duke <[e-mail]>]

As responsible AD, I tried not to give drafts a careful read until they are
ready for AD Evaluation. As I'm no longer AD, this document has slipped in
between a timely individual review and an AD eval, so here is my late
individual review of the acc-ecn draft.

High level editorial comments.  I'm afraid that these don't have easy
fixes, but of course you're free to ignore them:

(1) This document is very hard to read. Part of it is that it's just
complex! There are lots of special cases. It's clear the authors have
thought deeply about all of them. and that detail is present in the draft.
I will not have to personally implement this, but if I did, I would much
prefer a document that went through sequentially what each end has to do.

(2) Part of the complexity is that this bleeds into sender-side behavior
(for example, 3.2.2.3 is largely about when to abandon marking ECT. IMO,
this is the purview of the ECN algorithm, and this would benefit from
narrower focus on how to negotiate AccECN feedback and how to interpret the
results).

(3) Another source of complexity is that extensive rationales accompany
each requirement. To the maximum extent possible, separating out rationale
into a separate subsection or appendix would make this draft easier to
implement -- possibly as a series of "threat models" that how the
requirements work together to mitigate the impact.

Major design details:
It seems like the ACE setting in the first pure ACK carries important
information. Of course, this pure ACK is unreliable, and it's not clear
from reading what the implications of this packet being lost are, and what
actions the server should take if so.

Minor Points:
I'm not sure I understand why endpoints SHOULD use SACK but, if so, MUST
use DSACK. Not having SACK would seem to create huge problems in
disambiguating the ACE field if the server transmits first, but the first
data packet is lost. DSACK is not mentioned anywhere in the document except
this requirement, so it's not clear what the impact is.

(3.5) "MUST NOT use reception of packets with ECT set in the IP-ECN field
as an implicit signal that the peer is ECN-capable."

I understand why this is the case, but why does it matter? The endpoint
should still be echoing received ECN without regard for what the sender is
doing with it, no?

Martin