论文标题
FLEC:通过应用程序限制的可靠性机制增强Quic
FlEC: Enhancing QUIC with application-tailored reliability mechanisms
论文作者
论文摘要
数据包丢失是当今网络中的常见事件。它们通常会导致应用数据的交付时间更长,因为重新启动是从此类损失中恢复的事实上的技术。重传是许多应用程序的好策略,但与网络编码相比,对延迟敏感的应用的性能差。尽管已经提出了不同类型的网络编码技术来通过传输冗余信息来减少损失的影响,但并未广泛使用它们。一些利基应用程序包括其自己的正向擦除校正(FEC)技术的变体,但是没有通用协议使许多应用程序可以轻松使用它们。我们通过在新标准化的Quic协议中设计,实施和评估新的灵活擦除校正(FLEC)框架来缩小这一差距。使用FLEC,应用程序可以轻松地选择满足其要求的可靠性机制,从纯正重传到各种形式的FEC。我们考虑三种不同的用例:$(i)$ bulk数据传输,$(ii)$文件传输带有限制性缓冲区和$(iii)$ delay-delay限制的消息。我们证明,诸如Quic之类的现代运输协议可以通过利用FLEC中的这种知识来提供更好的损失恢复和流计划,从而受益于应用程序知识。我们对各种场景的评估表明,FLEC框架从潜伏期角度优于标准的Quic可靠性机制。
Packet losses are common events in today's networks. They usually result in longer delivery times for application data since retransmissions are the de facto technique to recover from such losses. Retransmissions is a good strategy for many applications but it may lead to poor performance with latency-sensitive applications compared to network coding. Although different types of network coding techniques have been proposed to reduce the impact of losses by transmitting redundant information, they are not widely used. Some niche applications include their own variant of Forward Erasure Correction (FEC) techniques, but there is no generic protocol that enables many applications to easily use them. We close this gap by designing, implementing and evaluating a new Flexible Erasure Correction (FlEC) framework inside the newly standardized QUIC protocol. With FlEC, an application can easily select the reliability mechanism that meets its requirements, from pure retransmissions to various forms of FEC. We consider three different use cases: $(i)$ bulk data transfer, $(ii)$ file transfers with restricted buffers and $(iii)$ delay-constrained messages. We demonstrate that modern transport protocols such as QUIC may benefit from application knowledge by leveraging this knowledge in FlEC to provide better loss recovery and stream scheduling. Our evaluation over a wide range of scenarios shows that the FlEC framework outperforms the standard QUIC reliability mechanisms from a latency viewpoint.