marten-seemann / draft-seemann-quic-accurate-ack-ecn Goto Github PK

As I was saying on the email list, it may be possible that the receiver receives a mix of CE and ECT packets which it may not ACK immediately due to more frequent CE marking in case of L4S.

The below field and the ACK_RANGES field assumes that ECN Marking will be same for all the packets from smallest to largest in that block. This may not be true. Probably a solution is create a new ACK Range for whenever the ECT value changes even if there is no gap.

First ACK Range {
  ACK Range Length (i),
  ECN Marking (8),
}

Basically cover two items:

1. Why knowing sequence of CE marked and non-CE marked packets is important. Coz it helps to order the AI and MD events accurately
2. Why knowing packet number for non CE marked packets is important. Coz from packet number, we can get the packet size, which gives us total number of non CE marked bytes used for AI.

In RFC 9000:

Assume you send a number of non-ack-eliciting packets and they get CE marked. These CE marks won't be reported at all.

Then after a while, you start sending data, and suddenly get an ACK frame that reports these CE marks. You now don't know if these are outdated or more recent CE marks.