More ECN verification failure modes

[martinthomson]

(From #2189)

There's a perverse situation in which ECN verification results in another problem.

That situation is where the largest acknowledged is lower on packet that is sent later. AND that packet acknowledges more packets so that the counts are higher. AND that packet is reordered ahead of packets with higher largest acknowledged. This results in the verification failing on the second packet to arrive (counts are lower because it's an older ACK, but the largest acknowledged is higher).

A fix is to never decrease the largest acknowledged when sending an ACK frame. Another is to disable validation if the packet containing the ACK is not higher-numbered than the last packet containing an ACK. The question is whether we care enough to recommend either fix...

@gloinul, WDYT?

[gloinul]

Maybe we need to bring back my proposed text to actually look that the PN of the packet containing the ACK frame is the highest received so far, else do not perform ECN verification. It requires a single state variable, and likely one per packet status boolean (wasReordered) to use during processing.
This I think got removed for more shorter and "elegant" text. That way all these reording things goes away. Without the reordering the ECN counters will never go backwards, even if an ACK, only ACKs what was an gap in what been acked so far.

[gloinul]

#2205 if there is a requirement for the ACK frame to always include a largest acknoweldge equal to largest received then the above can't happen. The the later reordered packet will have the same largest acknowledged as the later arriving, but sent later. Thus, the ECN verification check would be that Largest Acknowledged MUST increase for verification to happen. Or one actually looks at the PN of the packet of the ACK frame to ensure that they arrive in order.

[gloinul]

I think the best in this case is to not preform vierfication for out of order ACKs.

The current sentence in Section 13.3.2 (-17):
"Counts MUST NOT be verified if the ACK frame does not increase the largest received packet number at the endpoint."

Which I interpret to mean that what PN the ACK reference (sender-receiver direction), rather than the PN of the receiver to sender direction. Can you @martinthomson fix that? That way #2205 can focus on the other aspect and ignore ECN as it would not care.

[ianswett]

@gloinul That would be my preference as well.