lsquic icon indicating copy to clipboard operation
lsquic copied to clipboard

ECN mirroring can differ between mini_conn and full_conn

Open constantinsander opened this issue 2 years ago • 3 comments

Hi,

we analyzed whether ECN with QUIC can be used in the wild [1] and found that some LiteSpeed Server instances first mirror ECN counters but then stop to do so leading to failed ECN validation. The behavior can also be seen in the interop runner between, e.g., picoquic and lsquic [2].

We found that the mini_conn part of lsquic always sends ECN counters in ACKs while the full_conn follows the "Enable ECN support" flag and can thus stop mirroring ECN. Is this behavior intended?

Best, Constantin

[1] https://arxiv.org/abs/2309.14273 [2] https://interop.seemann.io/logs/2023-10-19T00:02/lsquic_picoquic/http3/client/test_log.txt

constantinsander avatar Oct 19 '23 08:10 constantinsander

Yes, that's expected behavior, if you need full ECN support, you should set ""Enable ECN support" flag, then the behavior will be consistent.

litespeedtech avatar Oct 24 '23 15:10 litespeedtech

Ok, yet, we would argue that it is better if the mini_conn follows the same flag. The current behavior first triggers ECN usage, due to the first ECN codepoints being mirrored, when then suddenly ECN mirroring stops. Depending on the ECN validation implementation of the sender this could lead to several packets being sent with ECT(0) and routers may signal congestion instead of dropping packets, but the sender cannot react to the congestion due to the missing mirroring, potentially rendering AQM techniques less efficient. If the mini_conn followed the same flag, ECN validation would fail early and the sender disables ECN.

constantinsander avatar Nov 02 '23 16:11 constantinsander