论文笔记：DTP: Deadline-aware Transport Protocol

摘要

越来越多的应用对数据交付有期限要求，例如 360° 视频、云 VR 游戏和自动驾驶。 这些应用程序通常非常需要带宽。 幸运的是，这些应用程序的数据可以分成多个具有不同优先级的块，从而可以通过优先处理一些块来减少带宽消耗。 然而，现有的传输层太原始，无法实现这一点。 因此，这些应用程序被迫构建自己定制的复杂轮子。 在这项工作中，我们提出了截止日期感知传输协议 (DTP) 来提供截止日期前交付（deliver-before-deadline）服务。 应用程序向 DTP 表达数据的截止日期和元数据。 然后 DTP 尝试通过调度块来满足要求。 与现有协议相比，DTP 提供了有意义的服务并减轻了应用程序开发人员的负担。

CCS 概念
• 网络→传输协议； 网络协议设计； 公共互联网。
关键词
截止日期、多路复用流传输、QUIC

1 Introduction

VR、AR、自动驾驶、超低时延游戏、大规模物联网系统等大量新兴应用正在快速商业化。 在最后一英里无处不在的无线接入、边缘/云基础设施的激增以及计算密集型机器学习和人工智能的进步的推动下，网络在支持这些应用方面发挥着越来越重要的作用。 例如，远程云预渲染高清 VR 场景，允许客户端以非常低的成本获取和渲染它们 [6]； AR 应用程序将复杂的对象识别任务卸载到附近的边缘 [7]； 自动驾驶汽车可以相互通信，使道路检测和路径规划更安全、更准确 [15]。 所有这些任务都需要来自强大、可靠和高性能网络的底层支持。

与传统的网络密集型应用程序（如 Web、FTP 和多媒体流）相比，上述新兴应用程序从网络流量工作负载和 QoE 要求的角度表现出几个独特的差异。

(1) 他们需要交付多个具有不同优先级的并发块。 以VR内容分发为例。 为了减少网络带宽消耗，最近的系统 [3, 13] 在空间上将场景划分为瓦片，并根据观察者的方向选择性地传输瓦片。 因此，图块的优先级取决于它被观看者感知的可能性。
(2) 应用程序的内容交付对延迟敏感 = 具有明确定义的截止日期。 对于 VR 内容交付，每个 tile 的截止时间是其播放时间减去本地处理时间； 对于联网车辆之间的 3D 环境共享，可以根据对象的距离和移动速度（运动矢量 [15]）计算 3D 对象（例如，进入的车辆）的交付期限。 如果不能在截止日期前交付内容，则交付工作可能会造成浪费。
(3) 应用程序应该能够动态调整优先级和截止日期，甚至在数据块传递到传输层的发送缓冲区后也能取消数据块。 例如，当 VR 服务器估计了更准确的头部姿势位置，或者当自动驾驶汽车更新 3D 对象的移动轨迹、距离或速度时，可能会发生这种情况.

在§2 中，我们展示了更多需要上述功能的示例。 诚然，它们可以在应用层实现。 许多现有系统确实这样做了，缺点是额外的开发开销和膨胀的应用程序代码库。 在应用层实现所有的传输特性也违反了网络的分层原则，使应用程序难以开发和维护。 此外，实现某些功能（例如取消一段已提交的数据）甚至可能需要高度侵入性的修改，例如注入 OS 内核模块 [13]。
受上述用例的启发，在本立场文件中，我们提出了 DTP（截止时间感知传输协议），这是一种支持上述功能的传输协议：内容优先级、截止时间、动态调整它们和取消排队数据。 因此，DTP 让开发人员专注于
应用程序逻辑（例如，如何计算截止日期）而不是应用程序所需的通用传输层机制（例如，如何强制执行截止日期）。 我们使用 QUIC 作为基础传输协议，因为它越来越流行，它的完整用户空间实现，以及它对并发流的支持[1]，为 DTP 提供了一个有用的构建块。

将其集成到 QUIC 中在几个方面都具有挑战性。
如何正确设计应用程序API？ 如何使 DTP 的基于数据块的内容交付与 QUIC 的面向字节流的范式兼容？ 如何允许一个块被安全地取消？ 如何设计一个同时考虑块的优先级和截止日期的调度器？ 我们在本文的其余部分提供高级解决方案指导。
总的来说，本文的贡献有两方面。
首先，我们确定了 AR、VR 和自动驾驶等新兴应用的常见传输层需求。 其次，我们提出了DTP并勾勒出其关键设计。 我们目前正在实施 DTP，并计划在实际应用程序中对其进行彻底评估，并将我们的实施开源。

2 背景和动机

360°视频和云VR/游戏等新兴应用对其数据传输有期限要求。 为了获得流畅的用户体验，他们使用了类似的技术，例如视口预测和传输优先级。 我们首先对这些应用程序进行案例研究，然后激发我们的新传输协议。

2.1 案例研究 1：360° 视频流

360° 视频在 YouTube 和 Facebook 等视频平台上越来越受欢迎。 用户在观看视频时可以自由改变观看方向，获得身临其境的体验。 它是通过基于用户的视口将全景屏幕投影到显示器上来实现的。 许多研究人员为 360° 视频开发了基于图块的流媒体 [9, 14]。 全景场景被分成许多瓦片。 它不是流式传输整个全景场景，而是仅流式传输落入用户视口的那些图块 [13]，或者与非视口图块相比以高质量流式传输视口中的图块 [3]。 然后在客户端，这些图块被并行解码并组合在一起。 一个图块的延迟将使整个视频流停止，否则用户将看到碎片化的内容。

2.2案例研究2:cloudVR游戏

虚拟现实可以为用户提供完全身临其境的体验。除了计算能力和手机的功能外，它还可以实现高质量的VR体验。为了克服这些限制，许多研究人员可以利用云/边缘计算能力来生成高质量的VRcontent并将其流式传输回移动设备。他们将VR场景拆分为多个切片和并行渲染，编码和传输。这类似于360°视频。与360°视频的不同之处在于，VR游戏内容可以分为动态的前景对象和相对静态的背景场景。它们有不同的移动补丁。前景对象是活动的，有时可能由用户操作。然而，当用户在虚拟世界中触发移动时，背景场景是相对固定的，并且只有变化，而虚拟世界移动的速度与用户在虚拟空间中的移动速度不同，或者与头部移动触发的视图端口变化不同。

基于这一观察，Zeqi等人[6]、Teemu等人[5]开发了名为Furion和CloudVR的协作渲染架构。移动设备负责渲染动态前景对象，云服务器处理背景场景渲染。CloudVR支持动态对象放置。当用户开始与对象交互时，将从服务器中提取该对象以进行本地渲染。Furion只有一个前景交互对象，但它可以根据用户在虚拟世界中的位置和移动来预测和预提取背景场景。Luyang等人[8]还开发了一个远程渲染无约束VR系统。它使用显示器VSync信号来同步客户端显示和远程服务器渲染。缺少VSync信号可能会导致严重的显示延迟。这个VSync延迟可以被视为对象传输的最后期限。

2.3案例研究3：协作增强车载现实

2.4新兴实时应用的常见传输要求

2.5当前传输协议缺乏支持

简而言之，这些应用程序需要一个传输解决方案
可以提供动态的、基于多块的和在截止日期前交付的服务。没有任何现有的传输协议能够提供这样的服务。TCP和UDP是面向单流的，它不知道数据传输的截止日期。
QUIC支持多流。每个流可以根据其RFC[4]被分配一个优先级。然而，它缺乏对截止日期的支持，并且在调度器中的优先级使用也没有得到很好的研究。QUIC还提供了可靠的交付，这与上述应用程序的实时性相冲突。这些应用程序更喜欢数据的新鲜度，而不是可靠性。实时传输协议（RTP）[16]确实支持新鲜度而非可靠性，但它不知道截止日期，也不提供基于块的交付。缺少对当前传输协议的支持概述如下
表1

如果没有适当的传输协议支持，应用程序将被迫构建自己的轮子。每个应用程序都必须处理数据的优先级排序、发送和确认等，这些都是繁琐而复杂的，导致代码库过于庞大。否则，他们只使用一些现成的协议，如TCP，这导致了较差的性能。我们建议使用期限感知传输协议（DTP）来提供此类服务。DTP遵循了策略与机制分离的经典原则。应用程序向传输层提供数据的需求和必要的元数据。元数据指示应如何传输数据的策略。传输层提供了实现策略的通用机制。策略执行过程的细节被封装在较低级别，这将应用程序从数据传递的微观管理工作中解放出来。

3设计

DTP是在QUIC的基础上扩展的，因为QUIC提供了许多有用的构建块，包括完全加密、灵活的拥塞控制和无对头阻塞的多路复用等。QUIC也是一个用户空间库，有许多得到很好支持的实现。在本节中，我们将讨论DTP的设计。

3.1架构

发送方Sender,架构如第3.1节所示。当块及其元数据从应用程序发送到传输层时，它将被放入专用缓冲区。然后调度程序将选择要发送的块。在那之后，分组器将把这些块划分成分组。拥塞控制模块负责发送数据包、收集ACK、进行数据包丢失检测。然后，它将丢失的数据放回每个块的重传队列。并将带宽和RTT等网络状态发送回调度器，以便于调度决策。

我们对QUIC架构做了一些更改。首先，DTP扩展了QUIC，以支持基于块的交付，而无需更改有线格式。QUIC RFC[4]需要QUIC实现来支持流优先级。因此，将块映射到流的直观方法是将具有相同优先级的块放在一个流中。通过这种方式，我们可以重用QUIC调度器的大部分来进行优先级排序。然而，这种映射面临着一个固有的问题。QUIC可靠的字节流性质与块传递的及时性和动态性相冲突。假设流1中间的一个块超过了截止日期，决定删除。没有简单的方法将指定的块标记为过时。现有的向QUIC添加不可靠或部分可靠传输的扩展无法实现这一点。Lubashev等人[10]建议将流的部分（到一定的字节偏移量）标记为不可靠。两种解决方案都不能指定不可靠的字节范围。此解决方案还引入了许多其他复杂性。例如用于流控制的最大块大小和最大流数据大小之间的冲突。如果总块大小超过流的流量控制限制怎么办？我们还需要另一个成帧子协议（指定分隔符）来组装要流式传输的块。这将引入额外的处理和传输开销。

我们采用另一种简单的方法：将块映射到QUIC流，一对一。如果决定丢弃块，我们只需使用现有QUIC协议的标准流取消过程，即发送RESET _STREAM帧来取消流。RESET _STREAM帧将触发流量控制更新，作为正常的QUIC。使用这种映射，我们也可以重用最大流数据大小作为最大块大小，因此在握手过程中不需要引入新的传输参数。我们还可以使用等式将块id映射到流id，而不破坏流id的语义。（1）。流类型位在QUIC RFC[4]中进行了定义。通过使用STREAM帧的FIN比特，接收机可以容易地确定块传输是否完成。
其次，我们禁用了将不同的流多路复用到一个数据包packet中，如QUIC RFC[4]中所建议的。原因有两个。首先是避免一个数据包丢失阻塞多个块的进程。第二是当其中一个块被丢弃时，简化重传过程。在没有多路复用的情况下，丢失分组的重传将涉及更少的有效载荷改变。
第三，调度器从拥塞控制模块获得联网估计。可以使用拥塞窗口（如Cubic）或传输速率（如BBR）来计算带宽。我们将默认的拥塞控制算法设置为BBR，因为它不会填充网络中的缓冲区。

3.2 API

正如第2.4节所指出的，应用程序真正需要的是基于块的交付。当我们谈论截止日期时，应用程序的有意义的截止日期是块完成时间，即在发送方生成块和在接收方将块提交给应用程序之间的时间。我们扩展了BSD socket API，让应用程序将元数据与数据块一起附加，如图2所示。这些元数据如下所示。

3.3 Deadline-aware scheduler

我们扩展了QUIC中的调度器，以便在选择发送方缓冲区中的块进行发送时考虑许多因素。时间表的目标是在截止日期前交付尽可能多的高优先级数据，并丢弃过时或低优先级的块。为了实现这一点，调度器利用拥塞控制模块提供的带宽和RTT测量以及应用程序提供的块的元数据来估计块完成时间。每当收到ACK或应用程序推送数据时，调度程序都会运行。
目前，QUIC中的调度器只会考虑流的优先级。然而，这种简单的算法在某些情况下无法获得最佳结果。假设带宽减少，并且调度器选择不发送低优先级流。然后恢复带宽。此时，优先级较低的数据块比优先级较高的流更接近截止日期。如果在这一轮中调度器仍然选择发送高优先级流，那么低优先级流可能错过下一轮的最后期限并被丢弃。在某些情况下，调度器可以选择发送低优先级流，因为它更紧急。但这样做应该不会导致高优先级流错过最后期限。
另一个需要考虑的因素是要传输的块剩余大小。在即将完成传输时丢弃块将浪费所有先前的资源，因为块的部分传递是没有意义的。

…… 一些优先级公式的解释

调度器算法的工作原理如下。首先，调度器根据应用程序指定的函数更新“real priority”值。如果实际优先级大于阈值α，该阈值也由应用程序设置。然后它将丢弃该块并发送RESET STREAM帧以通知另一端。之后，返回具有最低实际优先级值的块。

4 相关工作

传统实时应用程序优化 关于如何提高传统实时应用程序的性能，有很多工作要做。 典型的例子是视频会议。 许多解决方案将应用层速率适配与网络传输相结合。 WebRTC、Google Hangouts、Apple Facetime 都采用被动方式来调整视频的比特率。 当发生拥塞时，无论如何它都会发送已经编码的帧，然后降低未来帧的编码比特率。 这个反应过程很慢，不能缓解拥塞。
Salsify[2] 提议将编码器和传输层协同设计，以根据网络容量微调编码帧大小。 但是，这种方式需要更换整个堆栈，并且不支持硬件编码器和解码器。

实时传输协议 支持这些实时应用的传输协议也有很多。 RTP 和 RTCP 是在 20 世纪 90 年代中期网络状况不佳时设计的。 为了利用这样的网络，他们设计了许多复杂的机制，如冗余、时间同步等。但是，由于其复杂性和许多仅针对媒体传输的优化，部署和适应较新的应用程序和网络环境并不容易。
帕金斯等人。 [12] 讨论了 RTP 和 QUIC 之间的映射，并扩展了 QUIC 以支持实时媒体传输。 帕默等。 [11] 提议扩展 QUIC 以支持视频流。 与他们的提案相比，我们的提案更普适，侧重于新兴应用程序的截止日期要求，而不是针对特定的现有应用程序进行优化。

5结论

受新兴实时应用程序的启发，我们设计了一种新的传输协议DTP，以满足数据传输的截止日期要求。我们进一步设计了一个新的调度器，在网络带宽有限的情况下对一些块进行优先级排序。我们的协议是基于QUIC扩展的，并且完全兼容QUIC有线格式。使用我们的协议可以让应用程序开发人员不用担心网络状况。