Subject: [tcpm] RFC3448 & AccECN

From: "Gorry (erg)" <[email-masked]>
Date: Sat, 19 Mar 2022 20:47:55 +0100

I have problems with the proposal for AccECN update to RFC3449.

I found the ID complex spec to read, as it digs into multiple ways to perform accurate ECN reporting, so when thinking about ACK modification in a router, it's not easy too see what level of transport processing is desirable.

The method seems robust to loss, and ought to work with tunnels, etc.

RFC3449 references RFC3168, which is itself updated. That seems oK to me.

The latest rev. of the AccECN ID says in the abstract:
“The document also specifies the
   treatment of this updated TCP wire protocol by middleboxes, updating
   BCP 69 with respect to ACK filtering.”

- I did not find a specification in 3.3.3 that looked like it would be accepted into a BCP. That concerns me, so I'm directing my comment to the requirements line, and the following the two bullets:

Bullet 1:

This bullet motivates that routers seek to detect the use of accurate ECN ("SHOULD determine if an ACK is part of a connection using AccECN"), I think that needs to be qualified if kept. For me there seems a possibility that this add more "complexity" to the ACK processing, and therefore less predictable behaviour. This does not feel like it is a "SHOULD" or is necessarily good practice.

Bullet 2:

This second bullet raises a concern that was motivated in 2.3, and I think that the text is useful as it warns, but does not propose. I think it is correct and proper to indicate that the use of AccECN can be impacted by routers that manipulate/thin ACKs.

At the moment, the related requirement as written is:
"SHOULD then preserve the correct operation of AccECN feedback.", which I didn't see specified.I think it could also be useful perhaps as you do to speculate that it might be beneficial to update these routers, however the current text does not seem to be best current practice, at best it seems too vague.  For instance: I'm not clear what the text advocates when a queue of accurate ECN ACKs build at an intermediary.

In summary, I think I don't understand the need for the Updates line, and I do not see a BCP-style recommendation emerging yet. Maybe we just need experience and a short draft could write down what the IETF recommendation is, if there is finally a need for a change?

Gorry