TCP and QUIC can both leverage ECN to avoid congestion loss and its retransmission overhead. However, both protocols require support of their remote endpoints and it took two decades since the initial standardization of ECN for TCP to reach 80% ECN support and more in the wild. In contrast, the QUIC standard mandates ECN support, but there are notable ambiguities that make it unclear if and how ECN can actually be used with QUIC on the Internet. Hence, in this paper, we analyze ECN support with QUIC in the wild: We conduct repeated measurements on more than 180M domains to identify HTTP/3 websites and analyze the underlying QUIC connections w.r.t. ECN support. We only find 20% of QUIC hosts, providing 6% of HTTP/3 websites, to mirror client ECN codepoints. Yet, mirroring ECN is only half of what is required for ECN with QUIC, as QUIC validates mirrored ECN codepoints to detect network impairments: We observe that less than 2% of QUIC hosts, providing less than 0.3% of HTTP/3 websites, pass this validation. We identify possible root causes in content providers not supporting ECN via QUIC and network impairments hindering ECN. We thus also characterize ECN with QUIC distributedly to traverse other paths and discuss our results w.r.t. QUIC and ECN innovations beyond QUIC.

翻译：TCP和QUIC均可利用ECN避免拥塞丢包及其重传开销。然而，这两种协议都需要其远端端点的支持——自ECN最初标准化以来，TCP的ECN支持率用了二十年才在互联网环境中达到80%以上。相比之下，QUIC标准虽强制要求ECN支持，但其规范中存在显著歧义，导致ECN能否及如何在互联网上实际应用于QUIC尚不明确。为此，本文对QUIC中的ECN支持情况进行真实环境分析：我们对超过1.8亿个域名进行重复测量，以识别HTTP/3网站，并分析底层QUIC连接的ECN支持情况。研究发现，仅有20%的QUIC主机（提供6%的HTTP/3网站）会镜像客户端ECN编码点。然而，镜像ECN仅是实现QUIC-ECN联用的必要条件之一，因为QUIC需验证镜像的ECN编码点以检测网络故障：我们观察到，通过此项验证的QUIC主机不足2%（对应不到0.3%的HTTP/3网站）。我们识别出两类根本原因：内容提供者未通过QUIC支持ECN，以及网络故障阻碍ECN运行。为此，我们还通过分布式方式对QUIC中的ECN进行测试以遍历其他路径，并就QUIC及超越QUIC的ECN创新技术讨论相关发现。