With few exceptions, the path to deployment for any Internet technology requires that there be some benefit to unilateral adoption of the new technology. In an Internet where the technology is not fully deployed, is an individual better off sticking to the status quo, or adopting the new technology? This question is especially relevant in the context of the Low Latency, Low Loss, Scalable Throughput (L4S) architecture, where the full benefit is realized only when compatible protocols (scalable congestion control, accurate ECN, and flow isolation at queues) are adopted at both endpoints of a connection and also at the bottleneck router. In this paper, we consider the perspective of the sender of an L4S flow using scalable congestion control, without knowing whether the bottleneck router uses an L4S queue, or whether other flows sharing the bottleneck queue are also using scalable congestion control. We show that whether the sender uses TCP Prague or BBRv2 as the scalable congestion control, it cannot be assured that it will not harm or be harmed by another flow sharing the bottleneck link. We further show that the harm is not necessarily mitigated when a scalable flow shares a bottleneck with multiple classic flows. Finally, we evaluate the approach of BBRv3, where scalable congestion control is used only when the path delay is small, with ECN feedback ignored otherwise, and show that it does not solve the coexistence problem.

翻译：除少数例外情况外，任何互联网技术的部署路径都要求单方面采用新技术能带来一定效益。在技术尚未完全普及的互联网环境中，个体究竟应维持现状还是采用新技术？这一问题在低延迟、低丢包、可扩展吞吐量（L4S）架构背景下尤为关键，因为该架构的全部优势仅当连接两端及瓶颈路由器同时采用兼容协议（可扩展拥塞控制、精确显式拥塞通知、队列流隔离）时才能实现。本文从L4S流发送端视角出发，探讨其在未知瓶颈路由器是否采用L4S队列、且未知共享瓶颈队列的其他流是否采用可扩展拥塞控制的情况下，使用可扩展拥塞控制协议时的表现。研究表明：无论发送端采用TCP Prague还是BBRv2作为可扩展拥塞控制协议，均无法确保其不会损害共享瓶颈链路的其他流，或免受其他流损害。进一步发现，当可扩展流与多个经典流共享瓶颈时，损害未必能得到缓解。最后，本文评估了BBRv3方案——该方案仅在路径延迟较小时采用可扩展拥塞控制并忽略显式拥塞通知反馈，结果表明该方案仍未能解决共存问题。