To Punctuality and Beyond: Meeting ApplicationDeadlines with DTP

0 ABSTRACT

摘要—许多应用程序对其数据传输有时限要求，例如实时视频、多人游戏和云端增强/虚拟现实。然而，当前的传输层API过于简单，无法满足这些要求。因此，如今的应用程序被迫构建定制且复杂的时限感知数据传输机制。

在本研究中，我们设计了适用于广域互联网的“时限感知传输协议”（DTP）以提供在截止日期前交付的服务。为了满足在不稳定网络环境下的多样化且有时相互冲突的需求，我们设计了“发送方主动丢弃”调度器和自适应冗余。

我们通过对QUIC进行扩展来构建DTP，然后开发了两个利用DTP的应用程序。广泛的评估表明，DTP易于使用，并且与基本的QUIC相比，可以带来显著的性能改进（1.2倍至5倍）。

1 INTRODUCTION

段落1：

许多应用程序对其数据在特定时间（即截止日期）之前到达有要求。未能在截止日期前到达的数据对应用程序来说是无用的，因为它将被更新的数据所取代。这类应用程序包括实时媒体和在线多人游戏。例如，视频会议系统的端到端延迟应保持在可接受的阈值以下（约100毫秒），以便参与者可以进行自然的互动[1]。新颖的应用程序，如移动虚拟现实（VR）卸载，要求运动到显示屏延迟低于25毫秒，以避免晕动病[2]。对于在线多人游戏，服务器每隔60毫秒汇总一次每个玩家的操作，并将其分发给其他玩家，以确保每个玩家的状态与服务器保持同步。错过了这轮同步的数据包将被未来的数据包覆盖。换句话说，它们对其传输都有一个截止日期的要求。

段落2：

在几个社群中，有大量的研究致力于满足数据传递的截止日期要求。第二层和第三层的技术以及网络内协作的努力要求对网络硬件进行修改，或者需要终端主机与网络元素进行合作，这在公共互联网上是不可行的。传统的耦合解决方案以及对传输协议的扩展都存在部署问题。在这项工作中，我们专注于为在公共互联网上运行的应用程序提供具有截止日期意识的传递服务。设计这样的传输协议在多个方面都具有挑战性。

1. 应用程序的传输要求多种多样。该协议应提供一个通用的抽象，让应用程序可以表达它们的要求并提供有用的元数据。

2. 与数据中心网络不同，我们既不能更改网络内的硬件，也不能规范其他竞争连接的行为，因此网络内的延迟是无法控制的。

3. 每个数据块可能具有不同且相互冲突的属性，如截止日期、优先级和依赖关系。

段落3：

为了解决上述问题，我们首先分析了代表性新兴应用程序的共同要求和属性（第二部分），发现它们都有多个具有不同优先级的数据块，因此可以将网络资源分配给优先级较高的数据块。

基于这些认识，我们提出了一种通用且易于使用的基于数据块的协议，我们将其称为DTP1，用于具有截止日期意识的数据传输。然后，我们分析了交付过程的延迟component，并发现通过“主动发送时丢弃”（ADS）调度和使用冗余，可以减少发送方的延迟和重传时间（第三部分）。

我们的ADS调度器在决定发送或丢弃哪个数据块时，会在截止日期、优先级和依赖性等多个相互冲突的因素之间进行策略性平衡。冗余模块只在即将错过截止日期时才会被激活，从而避免了产生过多额外开销的同时减少了重传延迟。

段落4：

使用DTP，应用程序可以传达与所需的元数据一起的截止日期要求，并获得有意义的反馈。DTP试图满足应用程序的需求并通知应用程序交付结果。此外，DTP可以将交付结果从接收者传递给发送者，让发送者调整要求。因此，DTP可以显著减轻应用程序开发者的负担。

段落5：

QUIC [13], [14] 是一个有前途的协议，提供了更精确的往返时延（RTT）和带宽估计，以及丢包检测。QUIC可以防止大部分中间盒的干扰，因此更易部署 [14]。这可能为遵守截止日期的交付改进和部署带来新的启示。我们以非侵入式的方式（第四节）基于QUIC实现了DTP，作为一个完全在用户空间的系统。评估结果显示，在带宽受限时，DTP可以比QUIC在截止日期前交付5倍的数据块，在存在丢包时可以交付1.2倍的数据块。我们开发了一个360°视频流应用程序。评估表明，使用DTP可以将用户体验（QoE）提高30%至500%。我们使用FFMPEG和TCP构建了一个多方视频会议应用程序。然后我们仅仅修改了5000行代码中的98行来集成DTP，并在用户体验上获得了30%的改善（第五节和第六节）

1. 我们设计了DTP，这是一个具有截止日期意识支持的新传输协议。在发送端，应用程序将数据和其元数据发送给DTP。DTP利用块的属性来安排块的传输。同时，当截止日期即将到期时，DTP利用冗余来避免重传。

2. 我们将DTP实现为QUIC的一个扩展。评估结果显示，在广泛的网络条件下，性能比QUIC提高了1.2倍到5倍。

3. 我们开发了两个使用DTP的应用程序。评估显示，DTP可以将它们的用户体验（QoE）提高至多5倍。

2 BACKGROUND AND MOTIVATION

融合360°视频和云端虚拟现实/游戏等应用程序对它们的数据传输有截止日期的要求。我们首先对这些应用程序进行案例研究，然后推动我们的新传输协议。

A. Case study

360°视频流。许多研究者为360°视频开发了基于瓦片的流媒体方法 [15]，[16]。全景场景被划分成许多瓦片 [17]，[18]，这些瓦片会被传输并行解码。视口中任何一个瓦片的延迟都会使整个场景停滞。因此，每个瓦片都有一个传输期限（播放时间 - 本地解码时间）。为了减少带宽消耗，只传输重要的瓦片（根据用户的关注）。跨瓦片编码会引入这些瓦片之间的依赖关系

云VR游戏。许多研究尝试利用云端或边缘计算能力来渲染高质量的VR内容，并将其流回移动设备。Lai等人 [2]，Kämäräinen等人 [19] 开发了一个协作渲染架构。移动设备获取并渲染动态前景对象，同时云端渲染背景场景，然后以全景场景的形式进行流传输。Liu等人 [20] 使用显示VSync信号来同步客户端显示和远程服务器渲染。错过了VSync信号可能会导致严重的显示延迟。这个VSync信号可以被视为对象传输的截止日期。

合作增强式车辆现实。自动驾驶车辆使用各种传感器，如激光雷达、雷达和立体相机来感知周围环境。然而，它们的感知范围有限，并且只能看到直线视线范围内的物体，因此无法感知远处或被遮挡的物体。为了克服这些限制，邱等人提出了增强式车辆现实（AVR）[21]，通过无线方式在车辆之间共享视觉信息，从而扩展了车辆的视觉范围。为了减少通信的带宽要求，发送者可以根据物体的距离/速度对一些物体进行优先级排序。

B. Insights

基于块的数据传输的截止日期要求。这些应用程序都以块的方式生成和处理数据，每个块都有明确的截止日期要求。块被定义为应用程序的最小可用数据单元。对于这些应用程序来说，部分传递的块是无用的。例如，视频/音频编码器将编码后的流生成为一系列块（I帧、B帧、P帧或GOP）。在多人游戏中，玩家的命令和世界状态将被打包成一个消息。对于网页浏览，HTML、CSS和JS可以被视为对象。甚至在文件同步中，大多数文件云系统也是以块为基础同步数据。

对于一个应用程序来说，有意义的截止日期是块的完成时间，即从在发送方生成块并提交给接收方的应用程序之间的时间。如果一个块在截止日期之前无法到达，用户体验将受到影响，整个块将变得无用（被更新的块所取代或不再需要）。在360°视频中，每个GOP中的每个瓦片都是一个块，而瓦片和对象的截止日期是其渲染时间减去本地处理时间。如果未能满足截止日期，视频将停滞或变黑。在云VR游戏中，每个背景场景和前景对象都是一个块。迟到的对象是无用的，因为用户的兴趣会发生变化。在自动驾驶中，每个3D对象都是一个块，其截止日期被设定为它不再被遮挡的时间。

具有不同特性的多个并发块。通常会有许多需要并行传输的块。这些块对应用程序性能有不同的影响，可以通过优先处理某些块而不是其他块来减少带宽消耗。在360°视频中，可以根据用户的视口设置瓦片的优先级。视口中心的瓦片相对于周围的瓦片具有更高的优先级。在云VR游戏中，前景对象的优先级和截止日期比背景场景更高且更紧迫。不同的前景对象还可以根据用户交互的可能性具有不同的优先级和截止日期。在自动驾驶中，不同的动态对象具有不同的优先级。设置对象优先级的一种方式是根据它对其他车辆的危险程度来设置。例如，快速接近的车辆相对于远处缓慢移动的自行车对后方车辆具有更高的优先级。

块依赖性。应用程序可能会使用复杂的编码方法来压缩块数据，通常涉及跨块的增量压缩。一个典型的例子是H264中的I/P帧和SVC编解码器中的基础/增强层。这些跨块压缩可以显著减少带宽需求，但会引入块之间的依赖关系。如果所依赖的块不能及时到达，那么依赖于它的块也没有意义。因此，在发送块时应该尊重这种依赖关系。

应用层面的自适应。为了应对网络波动，应用程序通常会开发自己的自适应逻辑。例如，它们通常会尝试将数据发送速率匹配到监测/预测到的带宽。360°视频流使用自适应比特率（ABR）算法来选择视频质量。云VR游戏会降低背景场景的帧率或分辨率。如何调整行为取决于每种类型的应用程序。自适应可能发生在发送端或接收端。然而，它们都需要来自传输层的网络状态反馈，至少需要块的传输结果。

C. Limitations of current transport protocols 传输层协议的限制

简言之，这些应用程序需要一个能够提供基于多个块的在截止日期前交付服务的传输协议。它应该支持多路复用，即可以并行传输多个块。每个块都需要具有自己的属性，如截止日期、优先级和依赖关系。目前没有现有的传输协议可以提供这样的服务（见表格I）。

在没有适当的传输协议支持的情况下，应用程序被迫自行开发解决方案。一个典型的例子是WebRTC，它将从编码到传输的所有功能都集成在一起，导致了数百万行代码的产生。然而，这些应用程序通常选择使用诸如TCP之类的现成协议，可能会导致性能下降。此外，有些解决方案不适合应用在特定的场景中。例如，虽然应用程序可以通过冗余来减少由丢包引起的延迟，但这样做可能会变得复杂或者效果不佳，因为它需要了解已发送的数据包、丢包检测以及其他传输层的特性。

理想情况下，应用程序只关心要发送什么，而传输层则决定如何发送。我们提出了截止日期感知传输协议（DTP）来提供这样的服务。DTP 使用主动丢弃发送者调度程序来解决发送端的延迟问题，并使用自适应冗余来缓解由丢包恢复引起的延迟。

3 DESIGN

DTP的设计遵循三个原则：

1. 端到端原则，因此DTP不需要对网络内的设备进行修改。DTP应尽可能将数据放置在它可以控制的端点上。

2. 对于各种应用需求（如截止日期、优先级和依赖关系）进行自适应。

3. 减轻应用程序开发者的负担。DTP处理短期波动，应用程序只需要根据长期的用户体验（QoE）或数据传递结果选择合适的设置。

要完成在截止日期前交付的任务，首先需要了解延迟的来源。我们可以将块的交付时间分为三个部分：

1. 发送端的延迟。当应用程序的数据速率高于瓶颈带宽时，数据将被缓冲。这种延迟会影响所有后续的数据块。

2. 网络传输延迟。这包括数据传输延迟（block size/bandwidth）和往返时延（RTT）。

3. 接收端的延迟。接收端需要等待丢失或重新排序的数据包到达。丢包检测和重传也需要时间。特别是当块的末尾数据包丢失时，这些情况不能被忽视。

我们使用了一个主动丢弃发送者调度程序（详见第三节-B）来减少发送端队列，从而降低了发送端的延迟，特别是对于重要的数据块。

为了获得较低的往返时延（RTT）并尽可能多地保留可调度的数据在发送端，DTP 需要采用不会过分填充网络缓冲区的拥塞控制机制。

当链路丢包较多且截止日期紧迫时，丢失尾部数据包会导致数据块无法在截止日期前完成。第三节-C中的冗余模块可以通过在等待丢包检测和重传之前恢复丢失的数据包来缓解这个问题.

A. Architecture

DTP的架构如图1所示，其中传输服务模块被组织成一个流水线。DTP使用标准的低延迟拥塞控制算法（BBR v2 [22]）以获得最低的往返时延（RTT）。通过使用BBR v2，DTP将队列从网络转移到发送方，从而可以由DTP进行控制。其他不会导致网络中队列过多的拥塞控制算法，如Vegas [23]，也是合适的。

DTP不定制拥塞控制，因此不会引起诸如公平性问题等带宽共享问题。

核心思想：

每个数据块及其元数据首先存储在专用的发送队列中。

然后，调度器模块将选择要发送的数据块并丢弃过时的数据块。

封装模块和冗余模块将把数据块分解成数据包流，并在必要时生成冗余数据包以减少重传延迟。

这些数据包将被发送到数据包发送和拥塞控制模块，该模块发送数据包，收集确认信息并检测丢失，类似于QUIC/TCP协议。丢失的数据包被放置在相应的发送队列前面，因此自然地优先考虑。

拥塞控制模块监控网络条件，并为调度器和冗余模块提供带宽、往返时延和丢包率的估算，从而促进调度和冗余决策。

在接收端，传输层将接收数据并重新组装数据块。这个过程与发送端是对称的。

为了计算数据块完成时间，发送方和接收方需要相互同步一些信息。接收方需要知道数据块的开始时间（即数据块到达DTP的时间）。发送方需要知道数据块的结束时间（即数据块的所有数据包被接收或接收方恢复时）。我们选择将数据块的开始时间发送给接收方，并将数据包接收时间与确认信息一起发送回给发送方（详见第 IV-B 节)。通过这种方式，双方都可以知道数据块的完成时间。发送方可以使用ACK的时间戳来估算单向时延。我们还设计了机制来处理端点之间的时钟不同步问题（详见第 IV-D 节)。

B. Active-drop-at-sender (ADS) scheduler

段落1：

如前文所述，调度器负责操作发送方的队列，以减少对于那些重要数据块的排队延迟。调度器的目标是在截止时间之前尽可能多地传输高优先级的数据块，必要时丢弃那些不重要的数据块。实现这个目标是具有挑战性的，因为在做出调度决策时涉及到多个相互冲突的因素。

第一个因素是远离截止时间的高优先级数据块与截止时间临近的低优先级数据块之间的冲突。发送前者可能导致后者错过截止时间，而发送后者可能阻碍前者的传输。

第二个因素是正在传输的数据块与等待传输的更重要的数据块之间的冲突。提前传输后者意味着放弃前者，造成网络资源的浪费，而等待前者完成可能会导致后者错过截止时间。

段落2：

针对上述提到的多个因素，一个简单的算法在选择要发送的数据块时只会考虑优先级。然而，这种简单的算法可能无法获得最优结果。假设带宽减少，调度器选择不发送低优先级的数据块。然后恢复了带宽。低优先级的数据块距离截止时间更近，比高优先级的数据块更接近截止时间。如果在这一轮中调度器仍然选择发送高优先级的数据块，那么低优先级的数据块可能会在下一轮错过截止时间并变得无用。在某些情况下，调度器可以选择发送一个低优先级的数据块，因为它更为紧急。然而，它应该在不导致高优先级数据块错过截止时间的情况下这样做。这个例子揭示了应用程序指定的优先级和截止时间所涉及的优先级之间的基本冲突。在安排数据块时，我们需要同时考虑这两种类型的优先级。

段落3：

调度器还需要做出的另一个决策是何时中断一个数据块的传输并切换到新的数据块，也就是说，进行抢占式调度。非抢占式调度显然并不是最优的。考虑一个简单的情况，当一个大的数据块已经在传输时，一个具有更高优先级和紧迫截止时间的数据块需要立即发送；否则它将错过截止时间。如果调度器不是抢占式的，新的数据块将无法被发送，同时带宽也会浪费在传输那个较旧且不那么重要的数据块上。因此，调度器必须是抢占式的。但是何时进行抢占式传输？如果调度器抢占过于积极，数据块将会频繁地被切换，可能没有一个数据块能在截止时间之前完成。DTP 使用了数据块未发送比例（即一个数据块尚未发送的数据量占总量的比例）来确定是否应该将该数据块切换出去。

ADS调度器使用公式（3）计算加权优先级p（数值越小表示优先级越高）的值，计算考虑以下因素：

1. 距离截止时间的剩余时间（公式（1））。一旦数据块被认定为逾期，将通过添加β值（公式（2））增加其加权优先级值。β值越大，截止时间越严格。当β足够大时，错过截止时间的数据块只有在没有新的数据块可发送时才会被考虑。

2. 优先级。公式（3）中的优先级考虑了应用程序指定的优先级和与截止时间相关的优先级。α调整了它们之间的权重。α值越大，应用程序指定的优先级就越重要。

3. 未发送比例。如果数据块几乎完成，最好完成其剩余部分，以免浪费网络资源

调度器在接收到确认信息（ACK）或应用程序推送数据时运行，以便能够快速响应网络波动和应用程序发送模式的变化。在每次运行时，调度器会更新非依赖数据块的加权优先级值，并选择具有最低加权优先级的数据块。如果计算显示某个数据块无法在截止时间前完成（剩余时间 < 0），DTP倾向于暂停发送而不是丢弃它。只有当数据块在发送端已经错过截止时间时才会被丢弃。换句话说，丢弃的数据块通常已经严重超期。当由于设置不合理的截止时间导致严重丢弃时，应用程序需要调整截止时间。

调度器维护着一个数据块依赖关系的有向无环图（DAG）。如果存在循环依赖关系，图将将循环依赖的数据块合并成一个大的数据块，以保持无环性。只有入度为零的数据块（不依赖于任何其他数据块）才会被调度器考虑进来。一旦数据块被传送或取消，它将从依赖图中移除。

C. Deadline-aware adaptive redundancy 截止日期感知的自适应冗余

段落1：

ADS调度器选择的数据块将被分解成一个数据包流，经过冗余模块以获得对丢失的保护。为了在不失去冗余保护的情况下减少计算和带宽开销，我们设计了一个自适应于应用程序发送模式和网络的冗余模块。

段落2：

冗余模块仅对那些不能容忍重传延迟的数据包进行激活。对于单个数据块而言，承载其数据的某些数据包可能会触发冗余，而其他数据包则不会。一个数据包的丢失检测需要一个往返时延（三次重复的确认），并且重传该数据包也需要一个往返时延。当一个数据包距离满足其截止时间不足两个往返时延时，冗余模块将被激活。

然后，冗余模块将使用基于数据块的前向纠错（FEC）方案为接下来的m个连续数据包编码n个冗余数据包。这m + n个数据包形成一个冗余组。如果应用程序无法提供足够的m个数据包，我们将使用空数据包作为原始数据包。接收到冗余组中的任何m个数据包都可以解码出所有m个原始数据包。我们在发送原始数据包后发送冗余数据包，以便在正常数据包的发送和接收过程中可以并行进行编码/解码过程。冗余模块的性能取决于m和n的选择。较大的m和n可以提供更好的保护，但也会引入更高的开销。空数据包也是另一种开销。我们策略性地设置和调整m和n，以在截止时间之前完成恢复而不会引入过多的开销。

当选择一个较大的m值时，可以提供更好的防止突发数据丢失的保护，但同时也会引入更高的额外开销；此外，解码延迟可能会更高，因为接收端需要等待最多m个数据包才能进行解码。如果应用程序要发送的数据包少于m个，那么剩下的原始数据包将会是空的，从而浪费带宽。我们选择将m设定为一个最大的值，以确保在冗余组中的每个数据包都不会错过它的截止时间，即m×MSS/bandwidth + 2 × RTT < 截止时间。如果超过一半的原始数据包是空的，我们会将m减半。解决这个问题的另一种选择是避免发送这些空数据包，而是将一个标志附加到最后一个原始数据包上。然而，如果丢失了这个数据包，将导致解码失败。这将使协议更加复杂，以实现原始的保护效果。

一个更大的n也可以提供更好的丢失保护，但会带来更高的额外开销。理想情况下，n应该能够覆盖丢失率，也就是说，n应该大于m乘以丢失率。然而，丢失率的测量可能会不准确，而且丢失模式（突发或随机）也是未知的。我们根据在过去8个往返时延（8个RTT也是一个BBR循环的持续时间）内的冗余组解码结果来选择n。当一个冗余组完成时（其中所有数据包要么丢失了，要么已被确认接收），我们会检查每个组的数据包丢失率。然后我们将n设置为覆盖过去8个RTT内的最大丢失率。由于冗余仅适用于临近截止时间的数据包，可能在一个循环内没有任何冗余组完成。在这种情况下，我们将使用丢失率测量来重新设置n，即n = m乘以丢失率。选择最大的丢失率将使n略微大于理想值，但会增加成功解码的机会。

4 IMPLEMENTATION

我们通过对QUIC进行扩展来构建DTP，因为QUIC已经提供了许多有用的基础组件。DTP的设计也可以在其他协议，如SCTP和TCP上实现。我们的实现基于Cloudflare的quiche [24]，它使用Rust编程语言实现了IETF QUIC。该实现分为核心QUIC状态机和无I/O的套接字管理部分，后者可以使用平台本地的API来编写。这样，实现可以在许多平台上运行。由于QUIC是一个快速发展的协议，我们的扩展应该是非侵入式的，以便我们能够快速跟进QUIC的新功能，并且对于那些使用QUIC的应用程序来说，采用DTP会更容易。

["无I/O的套接字管理部分" 意味着这个部分负责处理套接字（socket）的创建、配置、连接、关闭等操作，但并不直接参与具体的输入/输出（I/O）操作。也就是说，它不直接负责发送或接收数据。

通常，一个网络应用程序会有两个主要部分：一个负责管理网络连接的部分，即套接字管理部分，另一个负责实际的数据传输，即I/O部分。在这种情况下，"无I/O的套接字管理部分" 强调了它只负责套接字的创建、配置等工作，而不直接参与数据的发送和接收。]

[非侵入式" 意味着对现有系统或流程没有负面影响或干扰。在上下文中，指的是对现有的QUIC协议的扩展不会破坏或干扰原有的功能或性能，使得新功能可以被快速地集成和采用。这样做的目的是保持对现有协议的兼容性，同时添加新的功能或特性。]

QUIC数据包由头部和一个或多个帧组成，这些帧携带着控制信息和应用程序数据。QUIC定义了20种帧类型，如STREAM、ACK、HANDSHAKE DONE等。扩展QUIC的自然方式是改变其帧格式或定义一个新的帧类型。为了在接收端和发送端之间同步块的元数据，DTP定义了两种新的帧类型：BLOCK INFO和BCT。为了估算单向时延，DTP在ACK帧中添加了时间戳。添加了FEC帧以实现冗余模块。为了使DTP的部署增量化，握手期间的版本协商和传输参数广告被修改为协商DTP的特性。如果协商失败，将回退到普通的QUIC协议。

A. Block-based delivery

DTP扩展了QUIC以支持基于块的传输。每个块都有自己的截止时间和优先级。在传输过程中，发送者可能会丢弃一些块。QUIC只支持可靠地传送多个流。我们需要找到一种将块的语义映射到QUIC流的方法。QUIC RFC [13] 要求QUIC的实现支持流优先级特性。基于此，将块映射到流的直观方法是将具有相同优先级的块放入一个流中。这样，我们可以在不对QUIC的传输格式进行任何修改的情况下，重用大部分QUIC调度程序以进行优先级排序。然而，这种映射面临一个固有的问题：QUIC可靠的字节流特性与动态块传送的及时性相冲突。假设流中间的一个块超过了它的截止时间并决定将其丢弃，那么发送者需要将特定的字节范围标记为丢弃，这意味着流传送不再可靠。这将破坏确认处理过程和流管理，使得扩展变得复杂。现有的扩展也不能将不可靠或部分可靠的传输添加到QUIC中。Tiesel等人提出了一个DATAGRAM帧，用于携带应用程序数据，而无需进行重传。但仅仅使用DATAGRAM还不足以实现块语义，因为它不支持流多路复用。

我们采用了另一种方法：将块一对一地映射到QUIC流。如果决定丢弃块，我们只需利用现有的QUIC协议中的标准流取消过程，即发送RESET STREAM帧来取消流。通过这种映射，我们可以重用最大流数据大小作为最大块大小。块标识可以通过使用方程式（4）将其映射到流标识，而不会破坏流标识的语义。由于QUIC流标识使用可变长度整数进行编码，最大值是（262 - 1)。这足以在一个会话期间保存块编号。即使块编号用尽了，我们也可以轻松地进行循环处理。通过使用STREAM帧的现有FIN位 [13]，接收方可以轻松确定块传输是否已完成。除非另有说明，DTP块的特性（如多路复用）与QUIC流相同。

B. Metadata sync

如第三节A部分所讨论的，DTP需要在发送端和接收端之间同步一些信息。

首先，DTP通过在QUIC中扩展ACK帧，添加了每个数据包范围内最后一个数据包的接收时间戳。

其次，由于QUIC是一种面向流的协议，接收端在接收到块的最后一部分之前无法知道块的大小。DTP添加了一个名为BLOCK INFO的新帧类型，用于向接收端传递块的元数据，如块大小、块开始时间、截止时间和优先级。每个字段都是可选的，并使用可变长度整数（1-4字节）进行编码。它会在任何块数据帧之前发送。

第三，DTP添加了一个名为BCT的新帧类型，用于传递预期的块完成时间与实际完成时间之间的时间差异。当接收端的应用程序将差异告知DTP时，它将向发送端发送一个BCT帧。BLOCK INFO和BCT帧都是可靠传输的，这意味着它们会触发ACK帧的发送。

C. Redundancy 冗余

DTP采用了与QUIC-FEC [26] 类似的方法，将明文数据包载荷用作源符号。与支持多种前向纠错方案不同，我们选择了Reed-Solomon编解码方案来实现冗余模块，因为它在计算开销和效率之间取得了平衡。通过固定方案，我们可以基于 [26] 进行一些简化处理。

第一个简化是，通过谨慎选择源符号的大小，DTP可以避免分割修复符号。QUIC-FEC [26] 设计了FEC帧以包含偏移字段，以处理修复符号大于单个FEC帧的情况。这样做可能导致修复符号被分成两个QUIC数据包，使得解码时间难以估计。由于修复符号的大小与源符号的大小相同，如果在选择一个数据包的明文负载作为源符号时考虑到可能的开销，我们可以避免修复符号跨越多个数据包。

选择源符号大小的过程如下。 通常情况下，QUIC数据包大小是一个常量值（MSS）。但也有一些特殊情况，负载可能具有不同的大小。 第一个特殊情况是数据包头的长度不同。在握手之后，QUIC对应用程序数据包采用了一种简短的头部格式。唯一一个长度会变化的字段是使用可变长度整数编码的数据包编号字段（可以是1/2/4字节）。当数据包编号即将跨越长度边界时，我们会在填充载荷的同时留出额外的空间，以确保跨越边界的载荷大小是统一的。 第二个特殊情况是当一个块的最后一个块无法填满数据包时。如果下一个块使用相同的冗余率，我们会将数据捆绑在一起。如果不是，我们会使用填充帧（PADDING frame）来填充载荷，这在QUIC协议中是可以自然理解的。我们修改了FEC帧，使其包含了冗余组的元数据，如组ID、组内载荷的索引、m、n以及符号。

第二个简化是DTP停止了重传，而无需定义任何新的帧类型。QUIC-FEC [26] 提出了一个包含成功恢复的数据包编号的新型 RECOVERED 帧。为了使接收方知道已恢复的数据包编号，每个数据包的数据包编号需要包含在源符号中，这将占用额外的空间。头部保护过程 [27] 将掩盖数据包编号字段，使得编码变得更加复杂。DTP通过利用Reed-Solomon编解码的特性，在发送方从ACK中推导出已恢复的事件，而无需进行实际的解码，从而避免了RECOVERED帧的使用。考虑一个包含m个原始数据包和n个冗余数据包的冗余组。由于QUIC数据包经过了认证，接收到任意m个数据包意味着整个组可以恢复。DTP要求基于块的编解码方案支持这种简化，并且不支持类似于RLC的滑动窗口解决方案。DTP的成功运行取决于编解码方案具有足够的缓冲区。

D. Handling clock synchronization error 处理时钟同步错误

使用发送方和接收方的时间戳来获取块完成时间和单向延迟需要在主机之间进行时钟同步。网络时间协议（NTP）[28]通常可以在互联网上保持时间精度在几毫秒以内[29]，这对于DTP来说已经足够了。但在极端情况下，误差可能会达到100毫秒或更多。

DTP通过利用来自应用程序的知识来解决这个问题。当一个数据块错过了截止时间，应用程序的用户体验将受到影响，接收端的应用程序将会注意到这一点（比如视频流卡顿，游戏同步在本轮中丢失）。如果丢失现象持续存在，那么当前网络下的截止时间设置可能是不现实的（可能是因为往返时延很长或时钟同步误差很大）。发送方应当调整其截止时间要求。

另一种可能的情况是端点（或端点）未同步时间。DTP使用系统误差参数来发现并解决这个问题。我们假设当往返时延保持稳定时，单向时延也是稳定的。对于每个数据包，数据包到达时间等于发送时间加上单向时延再加上系统误差。系统误差包括单向时延估计的误差以及发送方和接收方之间的时间同步不准确性。当往返时延稳定时，发送方会比较实际到达时间和估计的到达时间以调整系统误差。当往返时延发生变化时，系统误差将会重新校准。这种方法类似于NTP的基本交互机制，在我们的实践中可以实现接近的精度。

E. Abstraction and API 抽象和API

我们扩展了套接字API，允许应用程序在数据块上传输时附加元数据，如图2所示。

fd表示连接ID。depending是当前数据块直接依赖的其他数据块的ID数组。

update和cancel函数用于更新数据块的元数据或取消传输。

我们设计了on dropped和on delivered来报告每个数据块的传输结果。在截止时间前传输的数据量存储在goodbytes中。数据块完成时间与截止时间之间的毫秒差异存储在delta中。接收端应用程序可以使用expect告知DTP预期的数据块完成时间与实际完成时间之间的差异。

DTP在数据块内提供有序和可靠的传输，但由于网络限制，不能保证所有数据块都会在截止时间前传输完毕。对于每个数据块，DTP会提供传输结果，例如当数据块完成时的完成时间以及当数据块被丢弃时的完成比例。应用程序可以使用传输结果来优化其性能.

5 DEVELOPING APPLICATION UPON DTP

在本节中，我们将讨论应用程序如何使用DTP。要使用DTP，应用程序需要确定每个数据块的截止时间、优先级和依赖关系。这些参数的选择应基于影响QoE的特定于应用程序的机制。例如，一个会议应用程序可以将音频帧的优先级设置得更高，并根据可接受的通信延迟或抖动缓冲区大小来设置截止时间。我们开发了两个使用DTP的应用程序，如表II所示.

A. 360° video streaming emulation

我们构建了一个360度视频流模拟器。该模拟框架类似于Flare [17]中的图2，但没有实际的解码和显示过程。该应用程序利用用户的头部运动轨迹来预测未来的头部运动，并将其转化为视口，从服务器请求视口内的瓦片。每个数据块有几个不同的质量版本。为了选择质量版本，应用程序运行一个简单的ABR算法，利用过去一秒钟内通过on delivered回调聚合网络容量，并选择在截止时间内允许的最高质量版本.

B. Video conferencing

我们使用DTP和FFMPEG实现了一个轻量级的视频会议应用程序。服务器向应用程序发送多个视频流。服务器将视频流分成一系列帧。同一视频流内的每帧拥有相同的优先级。应用程序将这些数据块放入每个流的抖动缓冲区中。视频解码器将等待抖动缓冲区至少包含100毫秒的数据才开始解码。应用程序确定要传输的内容，而DTP决定如何传输。编解码器和传输协议的耦合性不像在WebRTC中那样紧密。我们基于TCP实现它，考虑到TCP仍然是最广泛使用的协议。由于DTP的API与BSD套接字类似，并且兼容流行的事件驱动框架，我们只需修改5K行代码中的98行，就可以将TCP替换为DTP。许多其他现有协议的接口，如UDP和SCTP，也与套接字API接近或兼容，因此迁移成本不会太大。

VI. EVALUATION

在本节中，我们在不同的网络条件和不同的应用程序下评估DTP的表现。除非另有说明，本节中的实验是在两台PC（Intel Core i5 3.4GHz，8GB内存）之间进行的，这两台PC运行的是Ubuntu 18.04，并通过模拟网络进行通信。两台PC的时钟时间是同步的。我们在一个单独的路由器上运行tc [30]来模拟各种网络条件，因为我们发现当在端点使用tc时，会出现与Kakhki等人[31]相似的错误结果。我们将DTP与QUIC和SCTP进行比较。对于QUIC的对手，我们选择了基于quiche版本的DTP的默认设置。我们不使用重置操作来丢弃QUIC的流，因为应用程序在没有DTP维护和提供的信息的情况下，无法知道何时取消一个流。我们基于QUIC实现了默认的SCTP调度器（先到先得），并且可以取消过时数据（表示为SCTP'）。DTP、QUIC和SCTP'都运行着相同的BBR拥塞控制算法，并且使用块到流映射进行苹果对苹果的比较。对于DTP，除非另有说明，我们设置α = 0.5，以平等地考虑截止时间和优先级，并将β设置为最低优先级值，这意味着倾向于放弃即将错过截止时间的块，以便处理新的块。

我们首先使用人工简单的网络和应用程序跟踪来研究DTP的行为（第VI-A节），然后在更现实的情况下展示其性能（第VI-B和VI-C节）。

A. Transport layer performance

首先，我们使用一个虚拟应用程序评估传输层的性能，以便我们可以在不同的网络条件下测试不同的流量模式。我们测量了虚拟应用程序所使用的CPU时间，并发现在发送相同数据量时，基于DTP的版本与基于QUIC的版本在CPU消耗上没有可观察的差异。在后续的实验中，我们考虑了三种DTP的变体：（1）只考虑截止日期（α = 0，表示为DTP-D）；（2）只考虑优先级（α = 1，表示为DTP-P）；（3）同时考虑截止日期和优先级（表示为DTP）。我们对所有测试运行了10次。每个测试运行一分钟。

1) Bandwidth variance 变化的带宽

我们首先调查DTP在不同带宽条件下的表现。应用程序每100毫秒发送三个具有不同优先级的200KB数据块。应用程序根据数据块的优先级对发送顺序进行排序。每个数据块的截止时间是200毫秒。所有数据块在截止时间前到达的带宽要求是6MBps。我们将带宽从1MBps变化到10MBps。我们将RTT设置为5毫秒，随机丢包率设置为0.01%。

图3a显示了在截止时间之前送达的数据块的比例。请注意，水平轴上标记的带宽是使用tc模拟的值。即使我们使用iperf [32]发送足够的UDP数据包，实际吞吐量总是略小于设定值。当带宽充足（> 6M）时，所有数据块都可以在截止时间之前到达。当带宽有限时，由于QUIC不丢弃过时的数据块，其性能迅速下降。

DTP-D和DTP-P的表现略逊于DTP，但比QUIC好得多。这证明了考虑截止时间或优先级可以提高按时交付的性能，并且结合这两个因素可以获得更好的效果。

DTP-D和DTP-P的表现略逊于DTP，但比QUIC好很多。这证明了考虑截止时间或优先级可以提升按时交付的性能，并且结合这两个因素可以获得更好的性能。DTP-D的表现不如DTP-P，因为仅考虑截止时间会导致大量的抢占。以5 MBps的情况为例，DTP-P调度器会发送前两个高优先级的数据块，它们可以在截止时间前完成。然而，DTP-D调度器在最接近截止时间的数据块变成最低优先级的数据块时，仍会选择发送它。发送一段时间后，调度器会发现其他数据块更接近截止时间，它会再次切换，浪费带宽传输最低优先级的数据块。

当带宽为5/3 MBps（仅足以在每轮截止时间之前完成两个/一个中的三个数据块）时，SCTP'的性能与DTP-P相同。回想一下，应用程序每轮都会根据优先级对数据块的发送顺序进行排序。SCTP'和DTP-P都会在每轮完成前两个/一个数据块，并取消剩余的数据块。当带宽为6/4 MBps时，实际吞吐量小于6/4 MBps。SCTP'的表现不如DTP-P。当新一轮的数据块到达时，SCTP'会继续发送旧的数据块，直到它们错过截止时间，但DTP-P会立即切换到更高优先级的数据块。只有当更高优先级/新的数据块完成且旧的数据块还未被取消时，DTP-P才会考虑未发送比例，完成剩余数据较少的数据块。这表明，基于优先级和未发送比例的策略性抢占可以提高性能。

当带宽为6 MBps时，每轮的前两个数据块可以在截止时间之前完成。至于第三个数据块，DTP-D会预测它会错过截止时间，所以它不会发送它。但是SCTP'会继续发送旧的数据块，直到它错过截止时间。这表明，主动放弃即将错过截止时间的数据块可以减少带宽浪费，从而获得更好的性能。综合以上所有因素，DTP始终表现最佳。

我们测量了在截止时间之前到达的数据（有效数据）。然后，我们将有效数据除以总数据量，得到有效数据比例。QUIC发送的大部分数据都错过了它们的截止时间，而其他四个竞争者发送的数据几乎可以达到100%的有效数据比例。这表明DTP可以更好地利用带宽来传输新鲜数据。

我们还测量了具有最高优先级的数据块在截止日期前完成的比例。结果如图3b所示。SCTP'的表现与DTP-P相似，除了在带宽为2MBps的情况下。在这种情况下，最高优先级的数据块所需的带宽是2MBps，而实际吞吐量小于2MBps。DTP将选择放弃旧的数据块，但DTP-P和SCTP将坚持它们。因此，DTP的性能优于DTP-P和SCTP'。DTP-D在带宽小于总需求（6MBps）时会在不同的数据块之间切换。因此，它的表现比DTP-P、DTP和SCTP要差。

为了进一步理解改进来自何处，我们测量了每个已完成数据块在发送端的平均等待时间（由于空间限制，图略）。当带宽不足时，QUIC不会丢弃数据，发送队列会积累。DTP在不牺牲数据块截止日期的前提下减少了等待时间。没有任何一个变种能够达到这种平衡，要么牺牲低优先级数据块的完成率，要么反复切换导致在发送端的延迟增大。

为了评估DTP如何响应动态带宽，我们在一次测试中改变了带宽。带宽在5秒时突然从12MBps降至4MBps，并在10秒时恢复（如图4中的灰色区域所示）。每个点代表过去一秒钟内的数据块完成率。与静态带宽的结果相似，DTP的表现始终是最好的。

2）Loss variance 变化的丢包率

接着，我们研究了DTP面对网络丢包时的性能表现。我们评估了在三种不同的流量模式下冗余模块的有效性。对于每种情况，我们将丢包率从1%变化到20%。我们设置了足够大的带宽以适应所有发送的数据块。

第一种流量模式是每100毫秒发送三个具有不同优先级的100 KB数据块。往返时延（RTT）为20毫秒。在这种情况下，由于自适应冗余，只有尾部数据需要被保护。我们通过计算额外发送的数据来验证这一点。例如，当丢包率为10%时，冗余模块只发送了大约3%的额外数据。对于第二种和第三种流量模式，我们模拟了在线游戏。每个游戏指令都非常小，通常小于MSS（最大报文段大小）。因此，我们将数据块大小设置为1 KB。我们将RTT设置为60毫秒，以便任何丢失的数据包都会导致数据块错过其截止日期。所有数据包都将获得冗余保护。结果是相似的。由于空间限制，我们只在图5中展示了稀疏的小数据块结果。在所有场景下，DTP始终优于QUIC。这表明冗余模块能够处理多样化的应用流量模式和丢包。

​​​​​​​B. QoE of applications

在本节中，我们评估了两个基于DTP构建的应用程序。基准测试是使用QUIC而不是DTP。

视频会议：我们向视频会议服务器输入8个不同的视频流。带宽从小于最小流量变化到超过8个流量组合的大小。丢包率设置为0.01%，往返时延（RTT）设置为在50到90毫秒之间波动。这8个流在接收屏幕上显示为8个方块。活动流（具有更高优先级）在接收方屏幕上将占据更大的区域，因此对图像质量有较大影响。我们将最高流的停顿计为应用程序的停顿。如图6a和6b所示，DTP可以减少停顿并提高视频质量，因为它可以提高最高优先级数据块的完成率。当带宽设置为6Mbps时，DTP的视频质量可以比QUIC提高5倍以上。

360度视频：我们使用多种真实轨迹运行我们的360°视频仿真器。我们使用来自[17]的用户头部运动轨迹。我们利用过去三秒内的头部运动数据，对接下来一秒进行线性预测。我们的360°视频轨迹包含汽车追踪、音乐会、野生动物和跳伞等内容。网络轨迹包含3G、4G、酒店Wi-Fi，并根据视频比特率进行了缩放。我们随机挑选这些轨迹的五种组合作为测试配置。每个测试运行五分钟，并重复10次。

首先，我们测量视窗内瓦片的平均比特率（图7a）。由于DTP丢弃了低优先级的数据块（视野之外的瓦片），因此更多的带宽被分配给视窗内的瓦片，使得DTP能够实现比QUIC更高的比特率。我们还测量了每单位时间的停顿时间。DTP的停顿时间低于QUIC（因空间限制省略了图表）。最后，我们测量了比特率变化频率（图7b）。由于DTP没有发送缓冲积累，它可以给应用程序提供更平滑的网络反馈。因此，在DTP中，自适应比特率（ABR）变化发生的频率比在QUIC中要少。

C. Real-world network evaluation

为了测试在真实世界网络环境下的性能，我们通过WLAN或蜂窝网络进行了两次测试。

蜂窝网络上的应用流量模式：我们在亚洲的一台阿里云服务器与连接商用4G网络的台式客户端之间进行视频流实验。我们使用各种视频流轨迹来评估DTP对不同数据块大小和动态网络的反应。图8展示了这些测试的结果。这些结果与在变化带宽下的传输层测试（图3a）相似，除了DTP-D的表现优于SCTP'。这可能是因为及时的抢占在变化的网络环境下提供了更多的好处。

WLAN下的360°视频：我们在北美的一台AWS服务器与笔记本电脑之间运行360°仿真器。我们在家里和餐馆进行测试。在家里测试时，同一WLAN下的另一台电脑正在运行占用带宽的应用程序，如流媒体4K视频。通过这种方式，我们可以测试DTP在其他流量干扰下的性能。当瓶颈存在于网络中时，队列将在发送方积累。DTP可以减少发送方的队列大小，从而如表III所示，可以改善QoE（用户体验质量）