CN105164982A - 通过指派丢弃优先级来管理流之间的带宽分配 - Google Patents

Abstract

在一个示例实施例中提供了一种方法，该方法包括生成传输控制协议(TCP)流；根据所选择的用来控制与TCP流相关联的吞吐量的比例，使用两个区分服务代码点(DSCP)中的一个标记TCP流的多个分组；以及将多个分组的至少一部分传送到网络。

Description

通过指派丢弃优先级来管理流之间的带宽分配

技术领域

本公开大体上涉及通信的领域，更具体地，涉及用于通过指派丢弃优先级来管理流之间的带宽分配的系统、装置和方法。

背景技术

与以前相比，端用户具有更多的媒体和通信选择。多个显著的技术趋势当前正在进行(例如，更多计算设备、更多在线视频服务、更多互联网视频流量)，并且这些趋势正改变着媒体递送场景。分别地，这些趋势逼近了容量的限制，并且还降低了视频的性能，其中这样的降低在端用户、内容提供商、和服务提供商之间产生了挫折。在许多情形下，需要递送的视频数据被丢弃、碎片化、延迟、或者仅是对某些端用户不可用。

适应性流送是用于通过计算机网络流送多媒体的技术。虽然在过去大多数视频流送技术使用文件下载、即看式下载、或者定制流送协议，但是大多数当今的适应性流送技术是基于超文本传输协议(HTTP)的。这些技术被设计为通过广泛分布的HTTP网络(比如，互联网)有效地发挥作用。

基于HTTP的适应性流送(HAS)通过追踪用户的带宽和CPU容量、然后在可用选项之间动态地选择恰当的表现形式(例如，带宽和分辨率)以供流送来运作。通常来说，HAS将平衡能够以多种比特率和分辨率(例如，表现形式)编码(其能够表示恒定比特率编码(CBR)或可变比特率编码(VBR))单一源视频的编码器的使用。播放器客户端能够基于可用资源在不同编码之间进行切换。理想地，这些活动的结果是对于高带宽连接和低带宽连接两者而言的好的视频质量体验、快速启动时间、和少许缓冲。

附图说明

为提供对本公开以及其特征和优点的更全面的理解，参考下面结合附图做出的描述，其中相同的参考标号表示相同的部分，其中：

图1根据本公开的一个实施例的、用于在适应性流送环境中管理流之间的分配的通信系统的简化框图；

图2A是示出了与涉及本公开的特定场景相关联的可能示例细节的简化框图；

图2B-2C是示出了与本公开的一个实施例的内部结构相关联的可能示例细节的简化框图；以及

图3-4是示出了与根据本公开的某些实施例的通信系统相关联的可能操作的简化流程图。

具体实施方式

概览

在一个示例实施例中提供了一种方法，该方法包括：生成传输控制协议(TCP)流；根据所选择的用来控制与TCP流相关联的吞吐量的比例，用两个区分服务代码点(DSCP)中的一个来标记TCP流的多个分组；以及将多个分组的至少一部分传送到网络。在此上下文中，术语“标记(mark)”包括与标识、标注、划分组、区分、分类、或以其他方式识别任何分组相关联的任何活动。另外，术语“控制(control)”意为包括与管理、调控、限制、划界、监管、或以其他方式控制给定参数相关联的任何活动。另外，术语“吞吐量(throughput)”意为包括涉及与客户端设备能够用来接收视频数据的任何路径(有线的、无线的、卫星等)相关联的带宽、容量、输出等的任何对象。

在更详细的实现方式中，这两个DSCP反映了将结合加权随机早期检测(WRED)协议来使用的HiDrop优先级和LoDrop优先级。另外，在HiDrop优先级和LoDrop优先级内的特定分组共享网络元件(例如，路由器)中的单一队列。在一个示例实例中，基本上HiDrop优先级中的所有分组都将在LoDrop优先级中的任何其他分组被丢弃之前被丢弃。另外，多个分组中的至少一些能够根据针对为TCP流配置的区分服务(Diffserv)优先级设定的最小值而被丢弃。

示例实施例

转到图1，图1是根据本公开的一个实施例的通信系统10的简化框图，通信系统10被配置为通过为多个HAS客户端指派丢弃优先级来管理多个适应性比特率(ABR)流之间的带宽分配。通信系统10可以包括多个服务器12a-b、媒体存储装置14、网络16、代码转换器17、多个基于超文本传输协议(HTTP)的适应性流送(HAS)客户端18a-c、以及多个中间节点15a-b。请注意，初始视频源可以是提取单一经编码源并且将其“代码转换"成多个速率的代码转换器，或者它能够是提取最初未经编码的视频源并且直接产生多个速率的“初级"编码器。因此，应当理解的是，代码转换器17代表任何类型的多速率编码器、代码转换器等。

服务器12a-b被配置为将所请求的内容递送到HAS客户端18a-c。该内容可以包括能够在网络中传播的任何合适的信息和/或数据(例如，视频、音频、媒体、任何类型的流送信息等)。某些内容可以被存储在媒体存储装置14中，媒体存储装置14可以位于网络中的任何位置。媒体存储装置14可以是任何Web服务器的一部分、在逻辑上连接到服务器12a-b中的一个、适合于使用网络16来访问等。一般而言，通信系统10能够被配置为提供与各种数据服务相关联的下载和流送功能。通信系统10还能够提供管理混合媒体产品的内容的能力，该能力可以将视频、音频、游戏、应用、频道、和节目组合成数字媒体束。

根据本公开的某些技术，图1的架构能够提供在竞争ABR客户端之间分配近似带宽份额以校正由于往返时间(RTT)多样性而导致的偏差的方式。客户端能够通过例如指示它们的请求的相对重要性来指定(或者至少影响)它们自己的带宽分配。这将涉及使用与请求相关联的任意数目的权重，如以下所详述的。这样的架构能够提供任意数目的优点。例如，本公开的某些实施例能够利用现有分组处理功能(例如，加权随机早期检测(WRED))，该现有分组处理功能已经广泛配设于现有网络设备上并且为现有网络所广泛接受。另外，该架构能够提供灵活的近似逐流(per-flow)服务区分，而实际上并不需要在网络中存在任何逐流状态。而且，这样的系统能够提供与其他流有关的带宽份额分配，而不是指定绝对带宽水平。本文所论述的某些技术能够在大范围的利用率水平上为ABR应用提供可观的实用性，同时仅需要最少的准入控制来防止网络资源的总量超载。

另外，本公开的教导能够提供可适用于ABR空间内的大范围的应用的通用、灵活的技术。该架构还能够提供一种即使有RTT多样性也能强化基本TCP公平份额的方式。而且，它不要求每客户端有多个TCP连接。另外，与要求使用多个TCP连接的解决方案不同，以连续的方式改变带宽分配是可能的。请注意，无论底层传输协议(例如，TCP、SCTP、MPTCP等)的行为如何，都能够部署这样的带宽管理范式。还应注意，这里描述的机制可以以不同方式用在不同应用中(比如，下面给出的示例)来实现不同带宽管理功能。

在以更清楚的方式详述这些活动之前，理解在包括HAS客户端的网络中遇到的一些带宽挑战是重要的。以下基本信息可以被看作可以适当地阐释本公开的基础。适应性流送视频系统利用多速率视频编码和弹性IP传输协议套件(通常为超文本传输协议/传输控制协议/互联网协议(HTTP/TCP/IP)，但是能够包括其他传输，比如HTTP/SPDY/IP等)，来向处于宽泛可变网络条件下的大量并发用户递送高质量的流视频。这些系统通常被用于“过顶(over-the-top)”视频服务中，这样的服务在网络路径上容纳变化的服务质量。

在适应性流送中，源视频被编码为使得相同内容可用于以多种不同速率流送(这能够经由多速率编码(比如，H.264AVC)或层次化编码(比如，H.264SVC))。视频能够被分成一个或多个画面组(GOP)(例如，通常为二(2)到十(10)秒的长度)的“区块(chunk)”。HAS客户端能够使用Web范式(例如，通过TCP/IP传输的HTTPGET操作)来访问存储于服务器上的(或者以接近实时直播的方式产生的)区块，并且他们依赖于用于数据递送的TCP/IP的可靠性、拥塞控制、和流控制特征。HAS客户端能够通过监测递送速率和/或它们的缓冲器的填充水平来间接地观察取回操作的性能，并且进而或者在带宽可用时上调至较高的编码速率以获得更好的质量，或者在可用带宽下降时为了避免缓冲器欠载运行和随之而来的视频停顿而下调，或者在可用带宽不变的情况下保持相同速率。与诸如传统有线TV或广播服务之类的非弹性系统相比，适应性流送系统使用显著较大量的缓冲来消减来自网络的变化带宽所引起的效应。

在典型场景中，HAS客户端将按区段从网络服务器取回内容。每区段能够包含节目的一部分，通常包括若干秒的节目内容。(请注意，在本公开中术语“区段”和“区块”可互换使用。)对节目的每部分而言，存在可以较高编码比特率和以较低编码比特率使用的不同区段：以较高编码比特率的区段比以较低编码比特率的区段需要更高的存储和更高的传输带宽。HAS客户端通过以下方式来适应于变化的网络条件：为所请求的每个区段选择较高或较低编码速率、当有较多网络带宽可用(和/或客户端缓冲器接近充满)时从较高编码速率请求区段、并且有较少网络带宽可用(和/或客户端缓冲器接近为空)时从较低编码速率请求区段。

当ABR客户端彼此在拥塞的网络上竞争带宽时，存在许多情形，其中对客户端、网络元件、和/或服务器而言能够以可预测的方式在竞争客户端之间分配可用网络资源将是有用的。在最简单的情形下，可能希望确保全部客户端接收到近似相等份额的可用网络带宽，即使到不同客户端的TCP连接的路径RTT可能不同。在其他情况中，可能希望一些客户端在持续基础上或是仅在短时间段内接收到显著大于其他客户端的带宽份额。非均等带宽分配可能有利的示例包括：

1.一个客户端订阅比另一客户端高的服务层，如在金/银/铜类型的服务中。在此情形下，订阅较高层服务的客户端应当接收更多带宽。

2.一个客户端试图在播出开始之前或者恰在频道变更操作之后快速地填充其缓冲器，而另一客户端已经具有充满的缓冲器。在此情形下，试图填充其缓冲器的客户端应当得到更多带宽，从而使得它能够更快地开始播出和/或比在其他情况下所可能的更快地调至较高编码速率。

3.由于由两个不同客户端同时显示场景的相对编码特性，所以就视频质量而言，一个客户端可能比另一客户端有更高的来自附加带宽的边际效益。例如，当前显示高速运动、高复杂度场景的客户端可能需要比略高的编码/下载速率较大的质量提升，而显示低速运动、低复杂度场景的客户端可能已经以相当的低编码速率具有最佳可能视频质量。在此情形下，具有额外带宽的较高边际效用的客户端应当接收较大份额的可用带宽。

本公开的一个目标是提供新型分布式机制，可以通过该机制来控制在竞争HTTP/TCP连接之间的带宽分配。虽然不限于此，但是在此公开的机制特别有效地适合于在ABR流送应用中使用。此外，所提供的架构利用了已经广泛部署在网络元件上并且已经为客户端所广泛接受和采用的服务质量(QoS)特征。

转到图2A，图2A是示出了可以与本公开相关联的一个可能架构的简化框图。图2A示出了多个TCP发送方，包括多个网络服务器31a-b和多个缓存节点33a-b，其中这些元件中的每个具有相应的分组标记模块35a-d。请注意，TCP流正在从这些元件向网络16传播，网络16包括路由器40。路由器40示出了区分服务等级和相关联的队列42，队列42考虑到HiDrop优先级44和LoDrop优先级46，它们各自具有指定的最小值，这将在下面进一步论述。请注意，在此上下文中术语“优先级(priority)”仅涉及(并且包括)准许路由器以某种方式区分队列中这两种类型的分组的任何类型的组织架构。例如，这能够包括使用任何适当的存储器、存储空间、队列、群组、划分等。路由器40还包括存储器元件48、处理器50、和WRED模块51。

使用不同丢弃概率对传输分组进行加权、随机化标记

图2A的架构与使用相同区分服务优先级内的两个区分服务代码点(DSCP)中的任一者来随机地标记TCP会话的每个传输分组相结合地利用了路由器中的WRED特征。在该特定示例中，两个DSCP代码点是HiDrop和LoDrop。假设路由器中的WRED配置被设置为使得：

(i)以HiDrop和LoDrop代码点标记的分组共享单一队列；

(ii)HiDrop优先级的分组将在LoDrop优先级的任何分组被丢弃之前被丢弃。这可能例如通过将HiDrop的WREDq_min值设置为显著大于LoDrop的q_min值来实现，如图2A中所示；以及

(iii)对HiDrop和LoDrop而言q_max近似相同。

在网络中以此配置的情况下，TCP发送方(在示例应用中通常为网络服务器或缓存节点)被设置为随机地并且按照对于该流(或者该流的一部分)固定的比例以HiDrop或LoDrop中的任一者来标记单一TCP流的每个传输分组。因为单一流的TCP吞吐量是响应于该流的分组丢失率的，所以被标记为HiDrop的分组的比例能够对该流的吞吐量有重大影响。

举个简单的示例，假设服务器正在发送两个视频片段并且假设在该时刻这两个片段正被发往同一目的地，从而对这两个流而言RTT和路径是相同的。然后，假设服务器将来自第一流的分组标记为HiDrop，但是仅将来自第二流的分组的1/4标记为HiDrop而剩余3/4被标记为LoDrop，按该1∶3比率在HiDrop和LoDrop之间随机选择。因为这两个流共享共同的瓶颈链路，并且由于被标记为LoDrop的分组将总是必然不会被丢弃，所以来自第一流的分组应当会经历近似为来自第二流的分组的四倍大的丢弃概率。因为TCP吞吐量通常反比于sqrt(p_drop)，所以系统预期第二流将具有第一流的吞吐量的两倍。

请注意，前述简单示例是在具有对架构正常发挥作用而言十分重要的两个额外考虑的情况下构建的，这两个额外考虑为：

1.共享队列中的流量是TCP友好速率控制(TFRC)流量。(例如，DCCP将运行良好，正如具有TFRC的RTP/UDP)；以及

2.队列中的每个TFRC流应当将其分组中至少某一合理比例的分组标记为HiDrop。

这两个额外考虑能够确保来自LoDrop的分组将总是必然不会被丢弃。因为流量是TFRC，所以仅丢弃来自每个流的小百分比的分组能够确保链路中的总体吞吐量受到控制。此外，要求每个单独的TFRC流具有最小百分比的HiDrop分组确保每个流的吞吐量可以被约束而不需要从该流丢弃LoDrop分组。

另外需注意，即使在极少的情况下来自LoDrop优先级的分组会被丢弃，也不会发生任何有害的事情。在发生这种情况的短暂的时间段内可能无法在流间实现预期的带宽份额，但是当该架构被用于支持ABR视频时，给系统目标功能带来的下降可以是相当小的。

请注意，本文描述的系统并不严格地限制于使用WRED。路由器中任何会导致根据上述(i)项和(ii)项的丢弃行为的技术都将起到良好的作用。因此，正在开发的用于差异化丢弃的新技术必然会利用本公开的教导。

RTT多样性的补偿

在经管理的网络内，在所关注的TCP流之间具有有界并且己知范围的RTT值的情况下，使用上述技术来在具有不同往返时间的流之间实现近似公平份额的带宽均衡是可能的。在本公开的示例实现方式中这将如下进行。

假设在经管理的网络上、并且在所关注的流之间，存在最小RTT时间rtt_min和最大RTT时间rtt_max。请注意，特定TCP流的RTT时间是TCP发送方已知的值(例如，在其TCP栈内)。另外，当TCP流在瓶颈期彼此竞争带宽时，它们通常将近似与它们相应的RTT值呈反比地共享带宽。

为补偿由不同RTT引入的非均等带宽份额，TCP发送方将以正确的比例设置分组中以HiDrop标记的部分以补偿较长RTT的影响。特别地，并且假设TCP吞吐量相对于RTT和分组丢失率的有利行为：

1.具有rtt_min(或更小)的RTT的流将使其全部分组被标记为HiDrop。

2.具有rtt＞rtt_min的RTT的流将使其分组的f_HiDrop＝(rtt_min/rtt)**2的部分被标记为HiDrop而其余被标记为LoDrop。

假设吐量相对于RTT和分组丢失率的有利行为，无论何时竞争TCP流在瓶颈期竞争时，以上机制应当对于竞争TCP流给出近似相等的吞吐量。而且，在实际场景中，对于RTT多样性的校正可在某种程度上比以上所表明的更复杂。此外，该校正可能不会在宽的RTT值范围内可靠地发挥作用。然而：

1.对RTT多样性的校正不需要应用于宽的范围。在经管理的网络中，情况可能经常是所关注的流仅源自少数位置并且这些位置相对接近目的地。

2.没有理由精确地运用上面给出的公式。试探法(Heuristics)可被用于校正例如对于长或短的RTT值的误差，或者甚至对于不同TCP栈的误差。

3.当该机制被用于管理去往ABR客户端的带宽流时，不一定要能够精确地或者以可重复的方式控制或者预测给定流所获得的带宽。因为ABR客户端在通过速率变换补偿带宽浮动时是非常有效的，所以不能精确地控制或者预测流的速率将会给端用户的体验质量带来极小的影响。

应当注意的是，更靠近预期结果(大多数时候)可以提供可测量的改进。例如，考虑大屏幕上的内容的两个观看者，但是其中之一具有为另一个的RTT的4倍长的RTT。如果系统什么也不做，这两个客户端可以按照4∶1的比率来分割带宽，这对于处于劣势的客户端而言是不希望的。如果系统尝试将带宽份额校正为1∶1，则它可以仅实现近似的结果(例如，1.5∶1)。然而，因为速率失真曲线通常是非常凸的，以1.5∶1分摊带宽可能仍大大好于以4∶1分摊带宽。

请注意，因为TCP连接的RTT时间可能在TCP连接的生命周期中显著变化(由于变化的队列延迟)，对RTT多样性的补偿应当在TCP连接的生命周期中被动态调整。为完成这一点，发送方可以监测对于连接的估计RTT值(如TCP栈所已知的)的改变并且相应地调整处于HiDrop和LoDrop的流量份额。

关于以上技术的一个可能的问题是如果太高比例的流量被指派到LoDrop(其将优先是无丢失的)，则该优先级可能难以承受。然而，假设每个TCP流具有某一合理比例的流量被指派到HiDrop，则这将不会是问题。因为仅有小的分组丢失率的情况下TCP吞吐量会显著降低，所以假定每个流具有足够多的分组处于HiDrop优先级则链路的总体吞吐量并且因此LoDrop优先级上的负荷应当易于被TCP拥塞控制所控制。

引入故意不公平

本章节的某些示例技术允许系统在竞争TCP流之间建立近似公平分摊，即使当在这些流之间存在RTT多样性时(至少在经管理的网络场景中)。对于ABR应用而言，下一个逻辑步骤是以可能对ABR应用有用的方式在流之间引入故意不公平。

为根据TCP流的重要性改变它们的相对带宽份额，系统能够简单地通过另一因子来对分组的被指派到HiDrop优先级的部分进行划分，以反映该流的相对重要性。例如，如果系统试图使得流A具有两倍于流B的吞吐量，则在计算每个流的分组的进入HiDrop的基准部分以便补偿RTT多样性而之后，系统将使流A的HiDrop部分除以4以使得它将具有两倍于流B的吞吐量。

在ABR应用中，通常是客户端具有关于在递送下一内容区段中或多或少的带宽的可用性的知识。因此，为允许客户端驱动带宽份额的分配的过程，系统能够引入信令机制，客户端(接收方)能够通过该信令机制使得服务器(发送方)获知应当被用于下一传输的相对权重。

转到图3，图3是能够用于辅助示出本公开的某些活动的简化流程图300。在一个特定示例中，系统能够假设在对下一内容片段的请求内，客户端能够通过信令向服务器通知介于0和1之间的实数w，该实数指示下一内容区段的相对重要性。这一般在302处被指示。(请注意，该指定重要性特性能够由任何网络元件来指派、由客户端设备自身来提供、由管理员(或权威人士)设备来提供等。)在304，当服务器接收到来自客户端的、对内容区段的请求时，服务器首先计算分组的要指派到HiDrop的部分以便补偿RTT多样性。接下来，在306，服务器使该数乘以(1-w)**2并且使用该值作为f_HiDrop的最终值。(请注意，在实践中，对w＜1的某些限制能够被用于防止任何客户端请求带宽的无限份额)。在308，当w接近于0时，该校正权重略微改变丢弃概率，并且该流将接收带宽的最小份额。随着w向1增大，该流的越来越少的分组被标记为HiDrop，并且正在讨论的该流的相对带宽份额相应地增大。这一般在310处被指示。

任何数目的技术可被用于将权重嵌入在片段内。示例实现方式可以将该权重值包含在请求的URL内，并且网络服务器处的应用能够从请求中分离出该权重值(例如，使用重写规则)。可替代地，能够使用HTTP扩展头部来传输权重。而且，任何数目的技术可被用于指示相对带宽份额和/或分组被指派到HiDrop优先级和LoDrop优先级相对概率。在此描述的技术(其中下一区段的重要性是使用介于0和1之间的实数来通过信令传达的)应当被理解为许多可能技术中的一种，客户端能够通过这些技术向服务器提供将允许服务器设置分组的被指派到每一优先级的部分的信息。

相对和绝对带宽份额

请注意该架构的技术不是实现将保证带宽分配给流而是允许客户端控制它们相对于其他客户端(并且相对于那些其他客户端还正在请求的带宽份额水平)的相对带宽份额。实际上分配给每个客户端的带宽能够取决于有多少其他客户端正在请求带宽，以及那些客户端指派给他们的请求的权重。例如，如果系统具有两个竞争客户端并且每个以0.25的权重请求片段，则每个将接收瓶颈链路的带宽的一半。如果系统使用这两个相同的客户端并且添加第三客户端，该第三客户端以0.5的权重请求带宽，则前两个客户端将各自接收1/4的链路带宽，而第三客户端将接收其余的1/2带宽。

与竞争客户端请求相比，这种基于相对份额的带宽分配使得本文描述的机制不同于通常已经用在用于基于媒体的应用的其他平台中的带宽分配机制。例如，在其他系统中，为媒体流分配带宽通常涉及对于适合于期望的媒体流的具体比特率的请求和分配，伴有沿着路径硬预留资源和/或相对于池准确地对资源计费。虽然这些“硬"预留被广泛地应用于旧有媒体应用，但是该架构的技术所提供的“相对份额”分配可用于ABR。

为给出示例，考虑客户端想要接收点播视频(VoD)流(其中内容是以恒定速率3.75Mbps编码的)的旧有视频应用。在此情形下，为获得好的体验质量，客户端和网络应该确保流在其整段持续时间内接收最小该固定速率3.75Mbps。确保该流将接收例如两倍于另一流的带宽将是没有价值的，如果这一带宽量结果发现仅为3Mbps而不是必须的3.75Mbps。

相反地，在ABR的情形下，考虑其中“金"客户端请求将接收两倍于“银"客户端的带宽但是不具有任何关于它实际将获得多少带宽的准确知识的场景。在繁忙时期，金客户端可以接收3Mbps且银客户端可以获得1.5Mbps，然而在较不繁忙时期，金客户端可以接收10Mbps同时银客户端可以获得5Mbps。假定可用带宽不下降到某一最小水平之下，则这些结果对于ABR而言可能是非常可接受且期望的，因为金客户端和银客户端仍然能够在非常大范围的可用带宽上提供可接受的体验质量(QoE)。请注意，即使是对于ABR，为了在总体网络负荷可能导致一些较重要的客户端下降到最小可接受的带宽水平之下时拒绝为较不重要的客户端服务，某种形式的准入控制是可取的。

为带宽份额确定权重值

为了将该架构用于客户端之间的带宽分派，各种技术能够被实现以设置ABR客户端在它们对于内容片断的请求中指定的权重值。在最简单的情形下，在不同情况下为客户端指派固定权重提供了重要的效用。例如，部署可以设置如下规则：“金”客户端按既定计划请求0.75的权重、银客户端请求0.5的权重、且铜客户端请求的权重为0，这分别向金、银、铜客户端提供4、2、1的带宽份额。这些简单的权重规则能够容易地增强以在客户端的缓冲器接近为空时允许更高的权重、或者根据显示内容的设备的类型(对较大的屏幕权重较高)。

用于设置权重的略微复杂一些的方法涉及使得客户端以某种“竞价”(权重类似于价格)的形式动态地适配它们所请求的权重，其目标是使得权重和得出的带宽份额最终收敛于一点上，在该点处对每个客户端而言附加带宽的边际效用是相等的，从而优化系统的全局效用。

用于使用速率失真模型分配带宽的架构的应用

以下论述示出了本公开的技术如何能够根据正在由ABR客户端显示的内容的速率失真曲线形式的特定模型被用于在一组竞争ABR客户端之间分配带宽。

转到图4，图4是能够被用于辅助示出本公开的某些活动的简化流程图400。如果做出如下假设(一般在402处示出)：有N个ABR客户端并且每个客户端正在观看不同的视频内容，则第i个客户端的速率失真曲线具有如下参数形式：

D_i(R_i)＝D0_i+C_i/(R_i-R0_i)

其中，R_i是针对客户端i的编码速率，D_i(R_i)是编码速率R_i处的失真，并且(D0_i，C_i，R0_i)是该客户端的速率失真曲线近似的参数。请注意，对于R-D曲线存在常用的参数。并且，请注意，在此形式中C_i参数是直观的“复杂度”参数。

如果我们进而假设该系统试图最小化(在404处示出)：

sum(D_i(R_i))

1＜＝i＜＝N

满足以下约束条件：

sum(R_i)＜＝R

1＜＝i＜＝N

其中R是总可用带宽。能够示出，如果R0_i很小(它在这些参数形式中通常如此)，则在对于任何i、i，R_i：R_j满足下式时，发生满足约束条件的对带宽的最优分配：

Rj：RJ＝sqrt(C_i)：sqrt(C_j)

在406处假设RTT相等，则将与sqrt(HiDrop_i)成反比地在流之间分割链路的总带宽，其中HiDrop_i是流i中的、具有较高丢弃概率的一部分分组。如果针对任何i和i设置下式：

HiDrop_i：HiDrop_j＝1/C_i：C_j

则带宽将被以完全正确的比例在流之间分割，以最小化系统中的全部客户端的总失真。这一般在408处示出。

假设C_min是所辨识出的最低复杂度参数，则在C_i＝C_min时系统能够将HiDrop_i设置为1，并且相对于较高复杂度参数的最大值缩放HiDrop_i的全部其他值。这一般在410处示出。

暂时返回到能够用于实现本公开的教导的某种内部结构，图2B是示出了HAS客户端18a的示例实现方式的简化框图。在此具体示例中，HAS客户端18a包括缓冲器52、处理器54a、存储器56a、和经修改的客户端应用模块55。图2C示出了服务器12a的一个可能实现方式，服务器12a能够包括处理器54b、存储器56b、服务器应用模块62、和服务器TCP模块64，服务器12a可以被用于执行使用HiDrop和LoDrop代码点的概率标记。

就与本公开相关联的示例组件、基础设施等而言，HAS客户端18a-c能够与想要通过某一网络在通信系统10中接收数据或内容的设备、客户、或端用户相关联。术语“HAS客户端”包括用于发起通信的设备，比如，能够在通信系统10内发起语音、音频、视频、媒体、或数据交换的任何类型的接收器、计算机、机顶盒、互联网无线电设备(IRD)、手机、智能电话、膝上型电脑、平板电脑、个人数字助理(PDA)、GoogleAndroid^TM、iPhone^TM、iPad^TM、或能够在通信系统10内发起语音、音频、视频、媒体、或数据交换的任何其他设备、组件、元件、端点、或对象。HAS客户端18a-c还可以包括适合于人类用户的接口，比如，显示器、键盘、触摸板、远程控制、或任何其他终端设备。HAS客户端18a-c还可以是尝试代表任何实体或元件发起通信的任何设备，比如，程序、数据库、或能够在通信系统10内发起交换的任何其他组件、设备、元件、或对象。本文档中所使用的数据指的是任何类型的数值、语音、视频、音频、或脚本数据、或任何类型的源或目标代码、或以可以从一点传送到另一点的任何适当的格式的任何其他合适的信息。

代码转换器17(或多比特率编码器)是被配置为执行一个或多个编码操作的网络元件。例如，代码转换器17能够被配置为执行一种编码到另一编码的直接数字到数字数据转换(比如，对于影片数据文件或音频文件)。这通常是在以下情形中做出的，其中目标设备(或工作流)不支持该格式，或者是具有要求减小的文件大小的有限存储容量。在其他情形下，代码转换器17被配置为将不兼容或过时的数据转换为能获得较好支持或更现代的格式。

网络16表示用于接收和发送通过通信系统10传播的信息的分组的互连通信路径的一系列点或节点。网络16在源和/或主机之间提供了可通信的接口，并且可以是任何局域网(LAN)、无线局域网(WLAN)、城域网(MAN)、内联网、外联网、WAN、虚拟私有网络(VPN)、或辅助网络环境中的通信的任何其他适当的架构或系统。网络能够包括任何数目的、彼此通过通信介质耦合(或通信)的硬件或软件元件。

在一个具体实例中，本公开的架构能够与服务提供商数字用户线路(DSL)部署相关联。在其他示例中，本公开的架构将等价地适用于其他通信环境，比如，企业广域网(WAN)部署、线缆场景、一般宽带、固定无线实例、到x的光纤(fiber-to-the-x，FTTx，这是针对在最后一英里架构中使用光纤的任何宽带网络架构的通用术语)、以及缆上数据服务接口规范(DOCSIS)有线电视(CATV)。该架构还能够结合任何3G/4G/LTE蜂窝无线和WiFi/WiMAX环境进行操作。本公开的架构可以包括支持传输控制协议/互联网协议(TCP/IP)通信的配置以在网络中发送和/或接收数据。

从更一般意义上来说，HAS客户端18a-c、代码转换器17、和服务器12a-b是能够辅助本文所论述的带宽分配活动的网络元件。如本说明书中所使用的，术语“网络元件”意在涵盖任何上面提到的元件，以及路由器、交换机、电缆箱、网关、桥接器、负载平衡器、防火墙、内联服务节点、代理、服务器、处理器、模块、或可操作来在网络环境中交换信息的任何其他合适的设备、组件、元件、专属设备、或对象。这些网络元件可以包括辅助其操作的任何合适的硬件、软件、组件、模块、接口、或对象。这可以包括允许对数据或信息的有效交换的适当的算法和通信协议。

在一个实现方式中，HAS客户端18a-c、代码转换器17、和服务器12a-b包括实现(或促进)本文所论述的带宽分配活动的软件。者能够包括服务器应用62、服务器TCP模块64、分组标记模块35a-d、和/或将促进本文所讨论的操作的任何其他合适的元件的实例的实现方式。另外，这些元件中的每个能够具有辅助本文所述的一些操作的内部结构(例如，处理器、存储器元件等)。换言之，这些带宽分配活动可以在这些元件外部被执行，或者被包括在一些其他网络元件中以实现预期的功能。可替代地，HAS客户端18a-c、代码转换器17、和服务器12a-b可以包括能够与其他网络元件协作以便实现本文所述带宽分配活动的软件(或往复式软件)。仍在其他实现方式中，一个或若干设备可以包括能够辅助其操作的任何合适的算法、硬件、软件、组件、模块、接口、或对象。

在某些替代实施例中，本公开的带宽分配技术能够被合并到代理服务器、网络代理、缓存、内容递送网络(CDN)等内。这能够涉及例如配设与这些元件之中的服务器应用模块62、和/或服务器TCP模块64、服务器TCP模块64、分组标记模块35a-d、分组标记模块35a-d的实例。可替代地，为了实现本文所论述的活动，能够在HAS客户端和这些元件之间交换简单的消息或信令。

在实践中，CDN能够提供内容向以下各项的高效带宽递送：HAS客户端18a-c或其他端点，包括机顶盒、个人计算机、游戏控制台、智能电话、平板设备、iPads^TM、iPhones^TM、GoogleDroids^TM、MicrosoftSurfaces^TM、用户驻地设备、或任何其他合适的端点。请注意，服务器12a-b(如先前在图1中标识的)还可以与边界缓存、网关、CDN、或任何其他网络元件相集成或耦合。在某些实施例中，服务器12a-b可以与用户驻地设备(CPE)(比如，驻地网关(RG))相集成。

如先前所指出的，网络元件能够包括实现带宽分配操作的软件(服务器TCP模块64、服务器TCP模块64、分组标记模块35a-d等)，如本文档在此所列出的。在某些示例实现方式中，本文所列出的带宽分配功能可以由编码在一个或多个非暂态、有形介质中的逻辑(例如，在专用集成电路(ASIC)中提供的嵌入式逻辑、数字信号处理器(DSP)指令、由处理器(图1中所示的处理器24a)或其他类似的机器执行的软件(可包括目标代码和源代码)等)中的逻辑来实现。在这些实例中的一些中，存储器元件(图1C中所示的存储器26a)能够存储用于本文所述操作的数据。这包括能够存储指令(例如，软件、代码等)的存储器元件，这些指令经执行实现本说明书中所描述的活动。处理器(例如，处理器24a)能够执行任何类型的与数据相关联的指令以实现本说明书中在此详述的操作。在一个示例中，处理器能够将元件或物品(例如，数据)从一种状态或事物转换为另一状态或事物。在另一示例中，本文所列出过的活动可以以固定逻辑或可编程逻辑(例如，由处理器执行的软件/计算机指令)来实现，并且本文所标识的元件能够是某种类型的可编程处理器，可编程数字逻辑(例如，现场可编程门阵列(FPGA)、可擦除可编程只读存储器(EPROM)、电可擦除可编程ROM(EEPROM))，或包括数字逻辑、软件、代码、电子指令、或其任何合适的组合的ASIC。

这些元件(例如，网络元件等)中的任何一个能够包括用于存储将被用于实现本文所列出的带宽分配活动的存储器元件。另外，这些设备中的每个可以包括能够运行软件或算法以执行本说明书中所论述的带宽分配活动的处理器。在适当的情况下并且基于特定需求，这些设备还可以将信息保存在任何合适的存储器元件(随机存取存储器(RAM)、ROM、EPROM、EEPROM、ASIC等)、软件、硬件中，或者在任何其他合适的组件、设备、元件、或对象中。本文所论述的任何存储器项目应当被看作涵盖于广义术语“存储器元件”内。类似地，本说明书中所论述的任何可能的处理元件、模块、和机器应当被看作涵盖于广义术语“处理器”内。每个网络元件还能够包括用于在网络环境中接收、发送、和/或以其他方式传送数据或信息的合适的接口。

请注意，虽然前述描述已经解决了某些ABR管理技术，但是当务之急是注意到本公开能够适用于其他协议和技术(例如，MicrosoftSmooth^TM流送(HSS^TM)、AppleHTTP实时流送(HLS^TM)、AdobeZeri^TM(HDS)、Silverlight^TM等)。另外，能够结合本公开使用的另一示例应用是通过HTTP的动态适应性流送(DASH)，其是能够容易得从本公开的技术获益的多媒体流送技术。DASH是适应性流送技术，其中多媒体文件被分成一个或多个区段并且被使用HTTP递送到客户端。媒体表示说明(MPD)能够被用于描述区段信息(例如，定时、URL、媒体特性、比如视频分辨率和比特率)。区段能够包含任何媒体数据并且能够相当大。DASH是编解码器不可知的。多媒体文件的一种或多种表示(即，以不同分辨率或比特率的版本)通常是可行的，并且能够基于网络状况、设备能力、和用户偏好来做出选择以有效地使能适应性流送。在这些情形下，通信系统10能够基于客户端、服务器等的个体需求来执行适当的带宽分配。

另外，应当注意到，就上面提供的示例而言，交互是按照两个、三个、或四个网络元件来描述的。然而，这仅是为了清楚和示例的目的而做出的。在某些情形下，通过仅参考有限数目的网络元件来描述给定一组流程中的一个或多个功能可能更容易些。应当理解通信系统10(及其教导)是易于扩展的并且能够容纳大量组件，以及更复杂/精细的布局和配置。因此，所提供的示例不应限制可能适用于无数其他架构的通信系统10的范围或者禁止通信系统10的宽泛教导。

同样重要的是应当注意到，附图中的步骤仅示出了可以由通信系统10执行或在通信系统10中执行的可能场景中的一些。在适当的情况下，这些步骤中的一些可以被删除或移除，或者，这些步骤可以被显著地修改或改变而不背离本公开的范围。此外，这些操作中的许多被描述为与一个或多个附加操作并发运行、或并行运行。然而，这些操作的定时可以被大幅更改。先前的操作流程是为了示例和讨论的目的而提供的。通信系统100提供了充分的灵活性，因为可以在不背离本公开教导的情况下提供任意合适的安排、时间表、配置、以及定时机制。

应当注意到先前的许多论述可能暗示单客户端-服务器关系。实际上，在本公开的某些实现方式中，在递送层存在大量服务器。而且，本公开能够容易地被扩展到在架构的更上游采用中间服务器，但是这不一定与通过“n”个服务器的“m”个客户端相关。任何这样的排列、缩放、和配置明确地在本公开的范围内。

本领域技术人员可以确定无数的其它改变、替代、变体、和修改，本公开意在包括落入所附权利要求的范围内的所有这样的改变替代、变体、改变、和修改。为了辅助美国专利和商标局(USPTO)和本申请上发布的任何专利的任何读者解释所附权利要求，申请人希望注意到申请人：(a)不意欲任何所附权利要求援引在其提交日即存在的U.S.C.第112节第35编第六(6)段，除非词语“用于…的装置”或“用于…的步骤”明确用在特定权利要求中；以及(b)不意欲通过说明书中的任何陈述以所附权利要求中没有反映的任何方式来限制本公开。

Claims (20)

1.一种方法，包括：

生成传输控制协议(TCP)流；

根据所选择的用来控制与所述TCP流相关联的吞吐量的比例，使用两个区分服务代码点(DSCP)中的一个标记所述TCP流的多个分组；以及

将所述多个分组的至少一部分传送到网络。

2.如权利要求1所述的方法，其中，所述两个DSCP反映在区分服务优先级内的HiDrop优先级和LoDrop优先级。

3.如权利要求2所述的方法，其中，在所述HiDrop优先级和所述LoDrop优先级内的特定分组共享网络元件内的单一队列。

4.如权利要求2所述的方法，其中，所述HiDrop优先级中的大多数分组基本上在所述LoDrop优先级中的任何其他分组将被丢弃之前被丢弃。

5.如权利要求2所述的方法，其中，根据为所述HiDrop优先级和所述LoDrop优先级设置的最小值，所述多个分组中的至少一些被丢弃。

6.如权利要求1所述的方法，其中，为了校正基于往返时间(RTT)值的差异的至少一个不平衡，所述多个分组中的至少一些被标记。

7.如权利要求1所述的方法，其中，试探法被用于调整所述标记以校正与一个或多个TCP流相关联的某些RTT值的误差。

8.如权利要求1所述的方法，其中，试探法被用于基于特定TCP栈调整所述标记。

9.如权利要求1所述的方法，其中，针对多个TCP流的相对带宽份额根据指定重要性特性被改变，并且其中，分组的被指派到HiDrop优先级的部分被另一因子分割以反映特定流的相对重要性。

10.如权利要求1所述的方法，其中，来自客户端的所请求的带宽权重在服务器处被接收，以便就要被应用到下一次数据传输的带宽特性的相对权重警示所述服务器。

11.如权利要求10所述的方法，其中，一个或多个客户端接收不同权重设置特性。

12.如权利要求11所述的方法，其中，所述应用中的至少一个应用基于对被分配有较多带宽的较高层服务的订阅而接收较高权重。

13.如权利要求11所述的方法，其中，所述应用中的至少一个应用至少部分地基于特定设备尝试填充其缓冲器或者至少部分地基于涉及所述特定设备的信道变更操作而接收较高权重。

14.如权利要求11所述的方法，其中，所述应用中的至少一个应用基于正被显示在特定设备上的场景的相对编码特性而被分配较高权重。

15.如权利要求11所述的方法，其中，基于一个或多个客户端设备以竞价协议来调整它们所请求的权重，至少一组权重被指定，在所述竞价协议中产生的带宽份额汇聚于一点，在该点处针对所述一个或多个客户端设备中的每个客户端设备的附加带宽的边际效用基本上是相等的。

16.如权利要求10所述的方法，其中，至少一组权重是基于复杂度参数的，该复杂度参数包括与特定TCP流相关联的至少一个失真特性和编码速率。

17.一种或多种包括供执行的代码的非暂态有形介质，所述代码当被处理器执行时能操作来执行以下操作，包括：

生成传输控制协议(TCP)流；

根据所选择的用来控制与所述TCP流相关联的吞吐量的比例，使用两个区分服务代码点(DSCP)中的一个标记所述TCP流的多个分组；以及

将所述多个分组的至少一部分传送到网络。

18.如权利要求17所述的非暂态有形介质，其中，所述两个DSCP反映在区分服务优先级内的HiDrop优先级和LoDrop优先级。

19.一种网络元件，包括：

处理器；

存储器；以及

模块，其中，服务器被配置为：

生成传输控制协议(TCP)流；

根据所选择的用来控制与所述TCP流相关联的吞吐量的比例，使用两个区分服务代码点(DSCP)中的一个标记所述TCP流的多个分组；以及

将所述多个分组的至少一部分传送到网络。

20.如权利要求19所述的网络元件，其中，所述两个DSCP反映在区分服务优先级内的HiDrop优先级和LoDrop优先级。