[论文解读] Performance of QUIC Implementations Over Geostationary Satellite Links

Sebastian Egger, Jörg Deutschmann+2 more|arXiv (Cornell University)|Feb 16, 2022

Service-Oriented Architecture and Web Services被引用 11

一句话总结

本文使用扩展版IETF QUIC-Interop-Runner（QIR-SE）在地球静止卫星链路上评估了多个QUIC实现的性能，该工具支持模拟和真实的卫星链路。主要发现表明，QUIC性能严重受限于高RTT和丢包，许多实现失败或吞吐量极低，性能高度依赖于客户端和服务器端的实现。

ABSTRACT

QUIC was recently standardized as RFC 9000, but the performance of QUIC over geostationary satellite links is problematic due to the non-applicability of Performance Enhancing Proxies. As of today, there are more than a dozen of different QUIC implementations. So far performance evaluations of QUIC over satellite links were limited to specific QUIC implementations. By deploying a modified version of the IETF QUIC-Interop-Runner, this paper evaluates the performance of multiple QUIC implementations over multiple geostationary satellite links. This includes two emulated ones (with and without packet loss) and two real ones. The results show that the goodput achieved with QUIC over geostationary satellite links is very poor in general, and especially poor when there is packet loss. Some implementations fail completely and the performance of the other implementations varies greatly. The performance depends on both client and server implementation.

研究动机与目标

• 评估多样化QUIC实现方案在具有高传播延迟且与性能增强代理（PEPs）不兼容的地球静止卫星链路上的性能。
• 扩展IETF QUIC-Interop-Runner（QIR）以支持卫星链路仿真和真实卫星测试，实现系统化基准测试。
• 识别在高RTT和高丢包卫星环境下QUIC实现中的性能瓶颈，特别是在无法使用PEP加速的情况下。
• 提供QUIC在卫星网络中不同客户端-服务器实现组合间性能差异和局限性的实证证据。
• 通过揭示实现特定弱点和在卫星环境中优化的机会，为未来QUIC开发提供指导。

提出的方法

• 扩展IETF QUIC-Interop-Runner（QIR）以支持地球静止卫星链路仿真和真实卫星测试，形成QIR-SE。
• 采用基于Docker的架构并结合ns-3网络模拟器，仿真高RTT卫星链路，包括有无人工丢包的场景。
• 使用真实卫星链路（如Astra等）和RTT超过600ms的模拟链路进行测量，评估吞吐量和传输行为。
• 利用pyshark收集并分析时间偏移图和数据包追踪，研究发送速率控制、重传机制和流动态。
• 在多个测试用例中，评估14种QUIC实现（如msquic、picoquic、lsquic、aioquic）的客户端-服务器组合。
• 通过公开网站自动化聚合和可视化结果，包括用于详细协议行为分析的时间偏移图。

实验结果

研究问题

• RQ1 在具有高RTT和潜在丢包的地球静止卫星链路上，QUIC性能如何随不同实现而变化？
• RQ2 客户端和服务器实现的组合在多大程度上共同影响QUIC在卫星网络中的整体吞吐量和可靠性？
• RQ3 为何一些QUIC实现尽管链路容量很高，却在卫星链路上完全失败或仅实现极低的吞吐量？
• RQ4 重传机制、发送速率控制行为以及丢包处理在高延迟路径上如何导致QUIC性能下降？
• RQ5 实现特定的设计选择在卫星网络约束下（尤其当无法使用PEP时）如何影响性能？

主要发现

• 总体而言，QUIC在地球静止卫星链路上实现的吞吐量非常差，许多实现的吞吐量不足物理链路容量的10%。
• 不同实现之间的性能差异极大，部分实现即使在理想条件下也无法完成文件传输，完全失败。
• 在SatLoss场景中引入人工丢包后，性能严重下降，数据速率显著降低，且由于高RTT导致恢复缓慢。
• 部分实现（如aioquic）从未达到稳定的传输速率，而其他实现即使在无人工丢包的情况下也表现出极高的完成时间波动，表明可能存在协议或实现层面的缺陷。
• 时间偏移图揭示了发送速率控制异常和过度重传问题——某些实现对每个原始数据包重传多达八次，导致10 MiB文件的总发送量高达6080 MiB。
• 结果表明，客户端和服务器实现对性能有显著影响，没有任何一个实现能在所有测试用例中始终表现更优。