Re: [quicwg/base-drafts] Add note about stale ACK frames breaking ECN (#2879)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I don't think that the conditions are quite right here.

> @@ -3154,11 +3154,13 @@ to be greater than the number of packets acknowledged in an ACK frame.  When
 this happens, and if verification succeeds, the local reference counts MUST be
 increased to match the counts in the ACK frame.
 
-Processing counts out of order can result in verification failure.  An endpoint
-SHOULD NOT perform this verification if the ACK frame is received in a packet
-with packet number lower than a previously received ACK frame.  Verifying based
-on ACK frames that arrive out of order can result in disabling ECN
-unnecessarily.
+Processing counts out of order can result in verification failure.  This can
+happen when packets containing ACK frames are reordered in the network, or if a
+sender retransmits an ACK frame with stale information.  An endpoint SHOULD NOT
+perform this verification if the ACK frame is received in a packet with packet
+number lower than a previously received ACK frame or if the ACK frame does not
+acknowledge any new packets. ACK frames that arrive out of order can result in

```suggestion
acknowledge any new packets. Validating ACK frames in those conditions can result in
```

> @@ -3154,11 +3154,13 @@ to be greater than the number of packets acknowledged in an ACK frame.  When
 this happens, and if verification succeeds, the local reference counts MUST be
 increased to match the counts in the ACK frame.
 
-Processing counts out of order can result in verification failure.  An endpoint
-SHOULD NOT perform this verification if the ACK frame is received in a packet
-with packet number lower than a previously received ACK frame.  Verifying based
-on ACK frames that arrive out of order can result in disabling ECN
-unnecessarily.
+Processing counts out of order can result in verification failure.  This can
+happen when packets containing ACK frames are reordered in the network, or if a
+sender retransmits an ACK frame with stale information.  An endpoint SHOULD NOT
+perform this verification if the ACK frame is received in a packet with packet
+number lower than a previously received ACK frame or if the ACK frame does not
+acknowledge any new packets. ACK frames that arrive out of order can result in

Question: is it possible to skip validation based on just one of these conditions?  I think that only the packet number condition is really necessary.

Rationale: Say I ACK 1-4 then later drop that range (for any reason) and ACK 5-9 in another packet.  If those packets get reordered, then when the first eventually arrives, it will have new acknowledgments, but it will still have bad ECN counts.  So you can't say that new acknowledgments is necessary.

The packet number is clearly the thing to use - and sufficient on its own - but would it be enough to look for increases in largest acknowledged?  ACK processors should not be expected to have access to packet numbers.  Allowing implementations to use largest acknowledged would depend on us not allowing that to regress, but that seems like it follows from existing advice.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2879#pullrequestreview-259262482