ECN counters and Coalescing of QUIC packets

[gloinul]

I realize there exist a need to clarify the text regarding ECN on the relation between IP packets and QUIC packets. As QUIC tracks QUIC packets, and not IP packets, this relation when coaleing occurs needs to be clarified. What I think is needed are:

• In Section 6.8: Using Explicit Congestion Notification should be updated to be explicit about when it talks about IP packet and when about QUIC packets.
• State explicitly that for coalesed QUIC packets, the IP packet's ECN field value is reported for each QUIC packet.

[martinthomson]

Sounds good. I'm sure that we'd appreciate getting a PR for this.

[gloinul]

So how do we deal with the different packet number spaces here. I see two options:
Either say that we totally ignore Initial packets in the perspective of ECN handling. Which basically delays the ECN verification until one sees ACKs for the 0- or 1-RTT packets. Or one requires one set of counters per packet number space. What are peoples preference here?

[martinthomson]

I'm thinking that you count separately, in the interests of keeping ACK accounting separate (and consistent). But no special handling, or disabling ECN for different phases. You can still use Initial/Handshake to verify that the path supports ECN.

[ianswett]

Agreed, each PN space has its own set of counters, and an ACK frame sent in a PN space conveys the counters of that PN space.