2012年10月11日
第10卷，第10期

发送端缓冲区以及多媒体自适应的案例

一项旨在提高流媒体视频和其他时间敏感型媒体的性能和可用性的提议

Aiman Erbad，卡塔尔大学；
Charles “Buck” Krasic，谷歌

互联网/Web架构已经发展到最受欢迎的站点通常以几乎无限的规模运行的程度，并且许多站点现在迎合数亿独立用户。性能和可用性通常对于吸引和维持此类用户群至关重要。因此，网络和服务器基础设施在用户争夺激烈的竞争中起着关键作用。网页应在最多几十到几百毫秒内加载。同样，站点努力维持多个九的可用性目标——例如，一个站点在一年内应有 99.999% 的时间对用户可用。

然而，实际上，此类严格的标准经过精心构建，以排除有问题的内容，例如视频流和交互式虚拟环境。如果站点将视频流缓冲事件计入其可用性，那么它们的多个九的可用性将瞬间消失。然而，有人可能会争辩说，在世界杯决赛进球的关键时刻发生视频缓冲，与社交网络用户在撰写帖子时重复某些步骤所造成的故障一样严重。本文的目标是提出自适应传输方法，最终旨在使流媒体视频和其他时间敏感型媒体的性能和可用性与传统 Web 内容的性能和可用性保持一致。为此，我们开发了一种名为 Paceline 的增强型传输。

随着高带宽低延迟多媒体应用（如视频会议、在线游戏和虚拟现实应用）在互联网上变得主流，它们将像现在其他高带宽（但高延迟）应用（如点对点文件共享）一样使网络饱和，尤其是在移动环境中。例如，视频会议正成为社交网站（例如，Google 中的 Hangouts）提供的一项常见服务。实时视频流比以往任何时候都更成为许多应用中不可或缺的组成部分，例如大型活动的直播（例如，奥运会、超级碗和世界杯）、远程学习和点播视频（例如，Netflix）。此外，全球视频游戏产业在 2012 年的规模为 640 亿美元，比电影产业更大。快节奏的大型游戏具有高带宽要求，¹ 因此它们不遵循网络游戏具有细通信流的旧观念。

流行的传输协议对高带宽和低端到端延迟的组合支持不佳。^3,8 Paceline 是一种旨在支持交互式、高带宽应用的增强型传输协议。与多媒体传输中的传统观念相反，Paceline 并非在 UDP（用户数据报协议）之上实现，也没有提议更改 TCP。更改或替换 TCP 的解决方案所面临的部署障碍和重复工作，超过了减轻其缺陷的挑战。相反，Paceline 使用了几种创新技术来解决 TCP 延迟问题。

除了 TCP 传输延迟之外，大型发送端应用缓冲区可能会累积并延迟重要数据，从而对感知质量产生更大的影响。为了使多媒体内容在各种环境（从千兆宽带网络到拥塞的无线链路）中具有优雅的故障模式，Paceline 使应用能够根据可用资源调整需求，并且它偏向于重要数据。它支持基于优先级-进度模型⁹ 的质量自适应，该模型已被证明在 TCP 上进行视频流传输时，在数据包延迟和抖动方面更稳定。¹⁰

端到端 TCP 延迟分析

由于交互性和传输延迟是这里的关键重点，让我们看看 TCP 延迟的来源，并为 Paceline 设置背景。如图 1 所示，端到端传输延迟通常分为四个组成部分：处理延迟（由处理速度导致）；节点（主机和网络路由器和交换机）中的排队延迟；由传输比特率导致的传输延迟；以及由物理距离引起的传播延迟。当其中一个或多个延迟变大时，交互性（应用到应用的消消息传递）将受到影响。在这四个延迟分量中，排队延迟（TCP 发送缓冲区和网络节点队列内部）是高带宽 TCP 应用延迟的主要原因。这被称为缓冲区膨胀问题。⁷

由于快速 CPU 和传输算法的精心设计，处理延迟通常可以忽略不计。传输延迟将受到以下因素的限制

延迟_传输 = mss/link_rate

假设目前 ADU（应用数据单元）适合传输段，直至mss（最大段大小）。对于常见值link_rate（Mbps 或 Gbps）和mss（例如，1500 字节），延迟_传输将很小（例如，亚毫秒）。这使得传播延迟和排队延迟成为延迟的主要贡献者。

单向传播延迟具有物理定律设定的下限。典型的 Internet 路径 RTT（往返时间）值在洲内距离为几十毫秒，或在跨越海洋或穿越卫星的路径上约为 100 或 200 毫秒。此外，TCP 通过重传提供可靠性，这可能会在总延迟中增加额外的排队延迟（传播延迟的倍数）。然而，在常见情况下，TCP 的快速重传机制应将重传引起的排队延迟限制为一个或两个 RTT。

更重要的是，TCP 的套接字缓冲区通常足够大，可能会导致秒级的排队延迟。在许多实际条件下，特别是由于 TCP 实现采用的大型内核套接字缓冲区，由发送端 TCP 套接字缓冲区引起的排队延迟是总延迟的主要部分。例如，对于 64 KB 的典型 TCP 发送缓冲区大小和 300-Kbps 的视频流，一个完整的发送缓冲区会贡献 1700 毫秒的延迟。为了避免不必要的排队延迟，可以更改内核以动态调整套接字缓冲区大小，从而在大多数时间将端到端延迟控制在两个 RTT 内，同时保持 TCP 的拥塞控制不变。⁸

Paceline 以此想法为基础构建，但旨在避免内核修改的需要。用户级方法避免了引入新的 TCP 实现的部署障碍，优雅地处理了可以击败基于 TCP 的方法的透明代理，并允许故障转移机制在 TCP 因背靠背丢失和重传超时而停滞时，减少最坏情况下的延迟。

数据服务模型：并非所有数据生而平等

在各种环境中，需求通常超过可用带宽，从而导致大型发送端队列。如果所有数据项都被同等对待并以 FIFO（先进先出）顺序处理，则队列可能会引入队首阻塞（当数据包行被第一个数据包阻塞时发生的延迟）并阻碍感知质量。最大限度地减少提交到 TCP 套接字缓冲区的数据量可以减少 TCP 发送端排队延迟，并将发送端缓冲区向上推送到 TCP 上面的层（在我们设计中的 Paceline）。本节描述了 Paceline 中的传输服务模型，以及基于优先级-进度模型管理发送端缓冲区所需的质量自适应机制。

Paceline 提供可靠的基于消息的服务模型，之所以选择它，是因为低延迟是主要目标，并且消息为应用提供了明确的方式来告知传输延迟偏好，以及表示 ADU。Paceline 的编程接口允许应用在每个消息的基础上指定消息重要性，并且 Paceline 按照重要性顺序传递消息。提前对消息进行排队的能力对于实现高带宽至关重要，但对消息进行优先级排序的能力对于防止不同重要性级别的消息之间的队首阻塞以及随之而来的响应性丧失是必要的。

与字节流服务模型不同，Paceline 允许发送方取消待处理的消息。此功能受响应性目标的驱动，因为旧数据可能会减慢新消息的速度并浪费带宽。结合拥塞控制，应用使用取消来调整消息传递速率以适应底层网络状况。知情的取消维护了可靠的传递语义，同时允许应用取消陈旧的消息。这为在拥塞情况下随机丢弃消息（例如，UDP）提供了替代方案。在接收器端，Paceline 将消息直接传递给应用。应用需要处理由消息优先级和取消引起的乱序传递和数据丢失。

在图 2 中，每个 ADU（例如视频帧或 Web 图像）都使用 Paceline 消息。每个消息都是称为流（例如，视频流或 Web 文档下载流）的全双工传输实例的一部分。与 SPDY²（一种为最小延迟而设计的应用层传输协议）类似，Paceline 支持多流，它在单个 TCP 通道之上多路复用并发流。应用可以对流执行以下操作：创建、发送消息、取消消息和删除。流与底层 TCP 通道解耦，因为具有相同主机地址和端口号的所有流都在同一 TCP 通道上多路复用。通道是底层通信原语，由主机地址和端口号标识。

与 SPDY 类似，Paceline 使用短寿命流（即，消息很少的流）在单个 TCP 通道之上高效地多路复用小型 Web 事务。更重要的是，其创新的公平性设计允许跨并发长寿命流（如视频会议或游戏）进行及时通信。不同的高带宽流可以共享链路，并且在延迟和高级应用质量指标（例如，帧速率）方面具有不同的要求。例如，游戏传输多种类型的流，例如玩家状态更新、玩家视频协调聊天、广告和游戏控制消息。如有必要，可以减少广告的频率，以帮助确保及时发送玩家更新。同样，远程学习会话可以从不同用户传输语音、视频和幻灯片，作为在同一 TCP 通道上多路复用的单独流，并且可以具有不同的质量指标。

为了帮助说明 Paceline 的服务模型，图 3 包含一个自适应实时应用可能使用的逻辑的伪代码示例，在本例中为自适应视频会议客户端。客户端调用send_video_frame函数以发送视频帧消息。此函数使用应用特定的效用度量来指定重要性来发送消息，该度量反映了单个帧对感知质量的相对重要性。如果拥塞控制限制了流的速率，则当低重要性消息的效用过期时，客户端将取消这些消息，而高重要性消息将被发送。对于重要性相同的消息，Paceline 根据位置打破僵局。Paceline 的服务模型为速率自适应提供了一个清晰的接口，以使应用需求与网络状况相匹配，而不是将消息提交到网络传输（即，套接字缓冲区），然后遭受传输排队延迟。

为了从 Paceline 的数据服务模型中受益，应用必须制定特定于领域的自适应策略。例如，高清视频会议具有空间和时间质量两个自适应维度。对于每个 ADU，应用计算一个重要性值来估计其对视频质量的贡献。每个 ADU 代表一个视频层并使用 Paceline 消息。

除了这两个质量维度之外，还可以合并更高级别的指标（例如，活动选项卡、鼠标点击和滚动条位置）以推导出自适应策略。同样，FPS（第一人称射击）游戏具有有限的上传带宽，以向所有游戏玩家发送频繁的更新，尤其是在大量玩家集中在一个区域的史诗般的战斗中。游戏可以使用诸如邻近度、最近度和瞄准之类的标准来降低带宽要求，因为玩家最有可能对附近的玩家或他们最近与之互动的玩家感兴趣。

架构

Paceline 以用户级库的形式实现，并分层在标准 TCP 实现之上。如图 4 所示，Paceline 的架构由两层组成：流层和通道层。流层管理 Paceline 中的应用消息队列，并通过启用一个流中和跨流的消息之间的自适应来确保对质量影响更大的数据的低延迟。此层由两个子系统组成：消息成帧和分片以及流公平性。通道层处理 TCP 低级发送端延迟。它由延迟控制器和连接管理器组成。

成帧和分片：发送哪个块？

分片是提高传输延迟的几种技术中的第一种。Paceline 允许任意大小的应用级消息。为了将可能很大的应用消息的传输延迟与较低级别的排队延迟解耦，数据传输机制支持将应用消息发送端分片为 Paceline 块，以及将块接收端重组为原始应用消息。块大小限制为较小尺寸，通常为 TCP 最大段大小的一部分。

Paceline 包括应用级消息队列。与以 FIFO 顺序运行的较低级别队列不同，Paceline 的消息队列基于优先级，因此新到达的重要消息的块可能会快速抢占较旧的、不太重要的消息的块。因此，具有高重要性的消息的块可以更快地释放到网络，并在 Paceline 内部观察到最小的排队，以及最小的应用级传输延迟。如果低重要性消息的整体传输延迟过大，取消允许应用中止该消息。

流公平性：来自哪个流？

Paceline 消息（和块）是全双工流的一部分。Paceline 中的每个流都有一个单独的优先级队列，其中包含准备发送的块。为了跨并发流进行公平和及时的通信，Paceline 支持两种公平性概念：质量公平性和资源公平性。资源公平性保证跨流的公平带宽，而质量公平性确保公平的应用级质量。质量以通用术语指定，但源自应用层；示例是视频会议中的每秒帧数或在线游戏中的每秒更新数。

虽然 FIFO 或轮询策略是在底层通道上多路复用不同流数据的简单方法，但及时性需要并发流之间更好的公平性概念，尤其是在带宽受限时。Paceline 在活动流之间实施了一种公平共享策略，该策略具有受加权公平排队启发的数据。每个流都有一个累积的虚拟时间，这是一个递增的计数器，用于量化流自创建以来已使用的资源。活动流按其虚拟时间顺序组织，并且块从具有最小虚拟时间的流发送。调节流如何多路复用的重要因素是它们的虚拟时间如何初始化和调整。

虚拟时间初始化基于两个规则

• 规则 1（公平启动）：创建流时，其虚拟时间设置为所有活动流的最小虚拟时间，以确保现有流不会饿死，直到新流在虚拟时间中赶上。如果不存在活动流，则新进入流的虚拟时间设置为所有空闲流的最大时间，或者如果这是唯一流，则设置为零。

• 规则 2（用进废退）：如果流在空闲后变为活动状态，则流的虚拟时间设置为其虚拟时间与所有活动流的最小虚拟时间中的最大值。这保证了没有流可以在空闲时保存其资源份额以供将来使用。

当流通过底层通道传输消息时，其虚拟时间会根据发送消息的虚拟时间进行更新，虚拟时间基于应用公平性标准。传统的资源公平性根据流传输的每个消息的大小来递增虚拟时间。另一方面，质量公平性根据应用体验质量的指标（例如，帧速率）来递增虚拟时间。通过使用不同的因子缩放不同流的虚拟时间，Paceline 可以为不同的流分配不同的份额，从而提供加权公平共享。

延迟控制器：发送多少个块？

为了让应用在自适应数据传递方面更灵活，Paceline 减少了 TCP 出站缓冲区中提交的数据量，并将数据保留在其自己的消息队列中。延迟控制器监控底层 TCP 流的进度，并调节传递到发送端 TCP 的应用数据（块）的速率。此控制器的目标是以足够快的速度将块发送到 TCP 中，以允许拥塞控制声明流的可用带宽的公平份额，但不要太快以至于在 TCP 的出站套接字缓冲区中累积不必要的 FIFO 排队。

Paceline 的控制器以动态匹配缓冲区填充级别的方式调节应用数据到 TCP 的写入，使其值接近 TCP 拥塞窗口的大小（cwnd）—即，cwnd+3χMSS。此设计在用户级别实现了与先前研究中在内核内部实现的相同策略，并且已证明在延迟和吞吐量之间实现了最佳平衡。⁸

Paceline 有两种不同的方案来估计cwnd：内核辅助方案和纯用户级方法。每种方案都有特定的优势。内核辅助方案称为 PaceK 控制器，它直接使用来自内核 TCP 的信息，通过套接字 API。虽然此方案简单有效，但它需要只有某些 TCP 实现才提供的信息。因此，PaceK 控制器并非完全可移植。此外，网络路径中的透明代理可能会破坏 PaceK 控制器调节排队延迟的能力，因为代理中的 TCP 套接字缓冲区独立运行，如果它们位于路径瓶颈之前，则很容易成为主要排队延迟点。

Paceline 中的纯用户级控制器称为 PaceA。与 PaceK 控制器不同，它仅使用所有主要操作系统上可用的通用 TCP 套接字 API。因此，PaceA 更具可移植性（无需扩展或修改内核）、更易于部署（例如，与防火墙相关），并避免了中间代理导致的问题。在用户级别，cwndcwndcwnd'不可用，因此 PaceA 的主要目标是导出cwndcwnd'cwnd'，对 TCP 的cwnd的估计。PaceA 使用应用级确认 (P-ACK) 来测量延迟和带宽，并将

cwnd'

估计为

延迟 χ 带宽

。有关 PaceA 设计的更多信息，请参见其他地方。⁵

连接管理器：使用哪个 TCP 套接字？

在 Paceline 中，延迟控制器是限制 TCP 延迟的基本技术。然而，在我们的实验中，消息延迟的分布保留了明显的尾部，并且中位数延迟和最坏情况延迟之间存在很大差距（例如，超过 8 倍）。我们通过 Paceline 中的工具和数据包跟踪分析诊断了最坏情况下的延迟。在严重拥塞的情况下，TCP 可能会遇到背靠背丢失，从而导致一个或多个重传超时。我们的诊断证实，最坏情况下的延迟与此类指数退避事件相关。在使用信号强度较差的无线链路测试 Paceline 时，也观察到类似的问题。为了减少它们的影响并对最坏情况下的性能引入上限，Paceline 包含一个故障转移机制，以补充其基本的延迟限制机制。

Paceline 的故障转移类似于用户在遇到响应缓慢时按下 Web 浏览器中的停止/重新加载按钮的情况。自动故障转移听起来可能相当激进，但我们的评估表明，我们的实现实现了最坏情况延迟的显着降低，同时保持了带宽公平性。自动故障转移类似于从 TCP 中删除指数退避，这在之前的工作中被证明是安全的。

连接管理器维护多个备份 TCP 套接字，并以对应用完全透明的方式实现故障转移。当达到阈值时，我们切换到新的 TCP 套接字。阈值设置受延迟和公平性之间的权衡影响，因为替换通道在 TCP 慢启动中启动，可能会导致网络利用率不足。故障转移阈值使用类似于 TCP 的 RTO（重传超时）的等式动态设置。在故障转移因子中添加了安全边际，以减少内核外部测量噪声引起的误报数量。

评估

我们在网络仿真测试平台中对 Paceline 进行了实验评估。我们的测量结果与两个参考点进行比较：TCP，用于量化 Paceline 带来的改进；以及 SST（结构化流传输），⁶ 在 UDP 上实现，没有传输缓冲区排队延迟。SST 提供丰富的服务模型，包括可靠的消息传递和拥塞控制，并且它包括人们可能期望从任何实际的全新 TCP 替代方案中获得的全部功能。因此，我们使用 SST 来近似最佳情况参考点，以此来比较 Paceline。

在 TCP 模式下，我们的应用仍然使用 Paceline 的服务 API，但延迟控制器被禁用；因此，我们通过 TCP 尽可能快地发送数据。

我们的网络设置使用常见的哑铃拓扑，其中 LAN 上的一组服务器通过单个带宽-延迟受限链路连接，模拟拥塞的 WAN 洲内路径，连接到远程 LAN 上的一组客户端。对于 WAN 路径，我们模拟 30 毫秒的 RTT 延迟，带宽限制为 16 Mbps 或 12 Mbps。WAN 瓶颈使用尾部丢弃排队，队列大小为 WAN 带宽-延迟乘积的两倍，当瓶颈变得拥塞时，增加 60 毫秒。实验设置为反映相当严酷的拥塞条件，其中瓶颈 WAN 链路持续饱和。这是 TCP 的性能非常不理想的范围。

传输性能摘要

Paceline 改进了 TCP 的弱点并保持了其优势。低级传输性能将 Paceline 与 TCP 的传输延迟、利用率和公平性进行了比较。Paceline 将中位数、99.9% 和最坏情况的端到端延迟降低了三到四倍。另一方面，Paceline 具有与 TCP 相似的带宽公平性、高网络利用率和合理的线路开销。Paceline 可在 Internet 上逐步部署，因为它与 TCP 流公平地共享带宽，同时保留所有延迟改进。（有关详细的传输性能，请参见 Erbad 等人 2010 年的“Paceline：通过自适应输出进行延迟管理”。⁵）

应用级性能：自适应是否有效？

本节评估自适应应用在应用级质量指标方面的性能。评估阐明了平均质量和交互性之间的权衡，然后显示了 Paceline 中相对于分配重要性的消息延迟。

质量和交互性权衡。 要考虑的主要问题之一是整体多媒体质量和交互性之间的权衡性质——更好的交互性（更低的延迟）通常以视频质量（例如，空间细节）为代价。以下实验将流的数量固定为八个视频（每个视频 4 Mbps，链路极度拥塞），但使用传出消息的延迟阈值（每个 ADU 在过期并被发送方取消之前给定的时间量）的配置参数来改变交互性级别。

为了量化接近用户体验水平的视频性能，我们以 fps（每秒帧数）为单位测量帧速率。视频会议测试应用中的自适应根据视频质量的两个维度对 ADU 进行优先级排序：时间质量（帧速率）和空间质量，使用帧的 PSNR（峰值信噪比）进行测量。视频格式是可扩展的，因此每个视频帧由八个 ADU 组成，其中一个基本空间层 ADU 和七个（渐进式）增强空间层 ADU。默认的自适应策略偏向于时间质量。也就是说，随着视频流的比特率下降，空间增强 ADU 被丢弃；当空间质量接近最小时，比特率的进一步降低将导致丢弃基本 ADU，这将导致丢弃整个帧（较低的时间质量）。因此，在用于测试的拥塞设置中，时间质量（即，帧速率）是质量度量。

图 5 显示了平均帧速率，因为延迟阈值是变化的。请注意，在图表的最右侧，延迟阈值最高（数十秒），所有传输都实现了视频的完整时间质量（30 fps）。当向左移动（使用较低的延迟阈值）时，使用 TCP 的时间质量下降得更快。即使 TCP 提供高吞吐量，TCP 的高传输延迟也会在低重要性 ADU（空间增强）和高重要性 ADU（基本层）之间导致频繁的队首延迟。这转化为丢帧和低得多的 fps 速率。

SST 和 Paceline 表现出的趋势非常相似。回想一下，SST 的实现完全避免了传输排队延迟。比较 Paceline 和 SST 的时间质量，我们看到 Paceline 也消除了大多数 TCP 发送端排队延迟。Paceline 和 SST 曲线在 100 到 200 毫秒区域的拐点表明，即使在这个高度拥塞的网络中，视频会议等应用也可能在合理的交互性区域内保持在质量影响适中的情况下。另一方面，使用 TCP 作为传输协议会导致质量在远超 500 毫秒点之前不会显着提高，这对于舒适的交互来说可能无法接受。

重要性对延迟的影响。到目前为止，Paceline 已被证明处于与 SST 等全新协议类似的响应区域内。本节调查重要性对消息延迟的影响。消息根据其重要性分布到存储桶中，并测量每个存储桶中已传递消息的单向端到端延迟。图 6(a) 显示了中位数延迟，而图 6(b) 是第 99.9 个百分位延迟。

如图 6 所示，TCP（具有自适应）和 Paceline 对于重要数据都具有较低的中位数和最坏情况延迟，与不太重要的数据相比，改进超过两倍。由于 TCP 将消息提交到内核发送缓冲区，因此 TCP 流具有更高的整体延迟，其中位数远高于预期延迟（即，275 毫秒）。另一方面，Paceline 使更重要数据的中位数延迟非常接近单向延迟（75 毫秒）。由于故障转移，Paceline 还具有一致的第 99.9 个百分位延迟，对于所有消息都接近 400 毫秒。TCP 中的第 99.9 个百分位延迟对于大多数消息都超过一秒，在某些情况下几乎达到 1.8 秒。

我们评估了 Paceline 中跨流的质量公平性。视频质量由时间质量（fps）定义。图 7 绘制了三个视频随时间的帧速率。视频（通过三个流传输）以相同的质量（在帧速率方面）显示，该质量根据网络条件而变化。有趣的是，注意到在同一时期为流分配了不同的带宽份额以实现相等的质量。

Paceline 通过写入 TCP 套接字缓冲区的最小量来减少发送方排队延迟。近年来，缓冲区膨胀问题重新受到了广泛的普遍关注和兴趣。 Kathleen Nichols 和 Van Jacobson 最近提出的算法是一个有希望的步骤，因为它易于实现且无需配置。¹¹ 然而，目前仍然缺少真正的端到端评估，以量化 TCP、ECN（显式拥塞通知）、AQM（主动队列管理）和自适应多媒体改进的总的综合效果。

我们感兴趣的根本问题仍然是一个悬而未决的问题：是否真的存在一条界限，某些应用程序出于交互性原因需要脱离 TCP？如果是这样，这条界限一直在随着时间推移而稳步移动。

经验教训

引入新的传输层具有挑战性，因为设计者必须解决几个关键问题。首先，传输层必须显著提高目标应用程序的性能，以证明额外付出的努力是值得的。其次，增强功能不应负面影响其他流量类型；我们坚持认为互联网应继续作为各种应用程序的通用基础设施。最后，传输层在延迟、公平性和利用率方面的性能改进需要转化为应用程序级别的质量改进。 Paceline 在所有这些方面都显示出了积极的结果。

我们使用广域网环境下的视频会议场景对 Paceline 进行了广泛的测试。 Paceline 还被用于一个小型基于云的游戏原型中，以扩展史诗级游戏场景的广域通信。¹³ 这两个应用程序都显示出多媒体质量的显著提高，这归功于 TCP 发送方延迟的减少以及 Paceline 中自适应的使用。

为了确保我们拥有支持广泛应用程序的通用传输，我们使用网络流量生成器模拟不同的 HTTP Web 流量类型（例如，HTTP1.0 和 HTTP1.1，带和不带流水线）。该实验测试了 Web 文档下载，同时改变了每页的对象数量和页面大小。随着对象数量的增加，Paceline 通过多流功能提高了带宽利用率，这是由于在底层通道之上自动流水线处理小事务的结果。

我们使用传输和应用程序质量指标评估了 Paceline。在开发 Paceline 算法的早期阶段，例如延迟率控制器和故障转移标准，传输级指标是必要的。在那个阶段，确保 Paceline 确实提高了延迟，同时又不降低公平性和网络利用率至关重要。然而，随着传输变得更加成熟，我们需要确保这些低级改进转化为视频和其他多媒体应用程序的质量改进。验证应用程序质量的改进是大多数新提出的传输的局限性。

最后，有效利用网络需要应用程序级别的质量和重要性度量知识，以及对消息的仔细跟踪以避免浪费带宽。质量自适应是一项重要的传输功能。 Paceline 使应用程序能够根据可用带宽扩展质量，并优先处理对质量影响更大的数据。自适应多媒体应用程序可以在带宽受限时提供具有不同质量级别的优雅降级模式，而不是重新缓冲。

Paceline 的实现是 QStream 视频流系统的一部分，该系统是开源的，可以从 http://qstream.org 下载。更多实现和评估细节可以在先前关于该主题的文章中找到。⁴

致谢

我要感谢不列颠哥伦比亚大学网络、系统和安全实验室的同事们对本文早期草稿的反馈。特别感谢 Mahdi Tayarani Najaran 对 Paceline 的设计和实现做出的重大贡献。最后，我要感谢 Terry Coatta 帮助改进了本文的风格和内容。

参考文献

1. Bharambe, A., Douceur, J. R., Lorch, J. R., Moscibroda, T., Pang, J., Seshan, S., Zhuang, X. 2008. Donnybrook: enabling large-scale, high-speed, peer-to-peer games. In Proceedings of the SIGCOMM Conference on Data Communication: 389-400.

2. The Chromium Projects. 2011. SPDY: an experimental protocol for a faster Web; http://www.chromium.org/spdy/spdy-whitepaper.

3. Erbad, A. 2012. Realtime support for interactive multimedia applications; http://hdl.handle.net/2429/42878.

4. Erbad, A., Hutchinson, N. C., Krasic, C. 2012. DOHA: scalable realtime Web applications through adaptive concurrent execution. In Proceedings of the 21st International Conference on World Wide Web: 161-170.

5. Erbad, A., Tayarani Najaran, M., Krasic, C. 2010. Paceline: latency management through adaptive output. In Proceedings of the First Annual SIGMM Conference on Multimedia Systems: 181-192.

6. Ford, B. 2007. Structured streams: a new transport abstraction. In Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications: 361-372.

7. Gettys, J., Nichols, K. 2011. Bufferbloat: Dark buffers in the Internet. Queue 9(11): 40:40-40:54.

8. Goel, A., Krasic, C., Walpole, J. 2008. Low-latency adaptive streaming over TCP. Transactions on Multimedia Computing, Commununications, and Applications 4(3): 1-20.

9. Krasic, C. 2004. A framework for quality-adaptive media streaming: encode once — stream anywhere. Ph.D. thesis. AAI3119036.

10. Kuschnig, R., Kofler, I., Hellwagner, H. 2010. An evaluation of TCP-based rate-control algorithms for adaptive Internet streaming of H.264/SVC. In Proceedings of the First Annual SIGMM Conference on Multimedia Systems: 157-168.

11. Nichols, K., Jacobson, V. 2012. Controlling queue delay. Queue 10(5), 20:20-20:34.

12. Nowlan, M., Tiwari, N., Iyengar, J., Amin, S., Ford, B. 2012. Fitting square pegs through round pipes: unordered delivery wire compatible with TCP and TLS. In Proceedings of the 9th Conference on Networked Systems Design and Implementation.

13. Tayarani Najaran, M., Krasic, C. 2010. Scaling online games with adaptive interest management in the cloud. In Proceedings of the 9th Annual Workshop on Network and Systems Support for Games: 9:1-9:6.

喜欢它，讨厌它？让我们知道

[email protected]

Aiman Erbad 最近加入卡塔尔大学计算机科学与工程系担任助理教授，此前他在不列颠哥伦比亚大学完成了博士学位。他的研究兴趣包括 Web 架构、网络、实时多媒体、普适计算和并发支持。

Charles "Buck" Krasic 在 Google 的 YouTube 从事大规模视频处理工作。在加入 YouTube 之前，他是不列颠哥伦比亚大学计算机科学系的教授。他的研究成果促成了 QStream 的开发。其他研究兴趣包括多媒体、操作系统、网络和分布式系统。

最初发表于 Queue vol. 10, no. 10—
在数字图书馆中评论本文

更多相关文章

Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更依赖基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，但也归功于一个名为 WebRTC 的开放、免版税平台。 WebRTC 的作用正在从实现有用的体验发展到对于数十亿人在疫情期间继续工作和教育以及保持重要的人际交往至关重要。 WebRTC 未来的机遇和影响确实令人着迷。

Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，并且用户采用率更高。

Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾将钥匙锁在房子或车里，您会对依赖循环感到熟悉。没有钥匙您就无法打开锁，但没有打开锁您就无法拿到钥匙。有些循环是显而易见的，但更复杂的依赖循环可能难以在它们导致中断之前被发现。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。

Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的运营商如何在租户系统所有者进行故障排除期间配置补救策略，同时帮助保持租户系统尽可能稳定。