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

文档序号:8947741阅读:来源:国知局
特率和以较低编码比特率使用的不同区段:以较高编码比特率的区段比以较低编码比特率的区段需要更高的存储和更高的传输带宽。HAS客户端通过以下方式来适应于变化的网络条件:为所请求的每个区段选择较高或较低编码速率、当有较多网络带宽可用(和/或客户端缓冲器接近充满)时从较高编码速率请求区段、并且有较少网络带宽可用(和/或客户端缓冲器接近为空)时从较低编码速率请求区段。
[0021 ]当ABR客户端彼此在拥塞的网络上竞争带宽时,存在许多情形,其中对客户端、网络元件、和/或服务器而言能够以可预测的方式在竞争客户端之间分配可用网络资源将是有用的。在最简单的情形下,可能希望确保全部客户端接收到近似相等份额的可用网络带宽,即使到不同客户端的TCP连接的路径RTT可能不同。在其他情况中,可能希望一些客户端在持续基础上或是仅在短时间段内接收到显著大于其他客户端的带宽份额。非均等带宽分配可能有利的示例包括:
[0022]1.一个客户端订阅比另一客户端高的服务层,如在金/银/铜类型的服务中。在此情形下,订阅较高层服务的客户端应当接收更多带宽。
[0023]2.一个客户端试图在播出开始之前或者恰在频道变更操作之后快速地填充其缓冲器,而另一客户端已经具有充满的缓冲器。在此情形下,试图填充其缓冲器的客户端应当得到更多带宽,从而使得它能够更快地开始播出和/或比在其他情况下所可能的更快地调至较高编码速率。
[0024]3.由于由两个不同客户端同时显示场景的相对编码特性,所以就视频质量而言,一个客户端可能比另一客户端有更高的来自附加带宽的边际效益。例如,当前显示高速运动、高复杂度场景的客户端可能需要比略高的编码/下载速率较大的质量提升,而显示低速运动、低复杂度场景的客户端可能已经以相当的低编码速率具有最佳可能视频质量。在此情形下,具有额外带宽的较高边际效用的客户端应当接收较大份额的可用带宽。
[0025]本公开的一个目标是提供新型分布式机制,可以通过该机制来控制在竞争HTTP/TCP连接之间的带宽分配。虽然不限于此,但是在此公开的机制特别有效地适合于在ABR流送应用中使用。此外,所提供的架构利用了已经广泛部署在网络元件上并且已经为客户端所广泛接受和采用的服务质量(QoS)特征。
[0026]转到图2A,图2A是示出了可以与本公开相关联的一个可能架构的简化框图。图2A示出了多个TCP发送方,包括多个网络服务器31a-b和多个缓存节点33a_b,其中这些元件中的每个具有相应的分组标记模块35a-d。请注意,TCP流正在从这些元件向网络16传播,网络16包括路由器40。路由器40示出了区分服务等级和相关联的队列42,队列42考虑到HiDrop优先级44和LoDrop优先级46,它们各自具有指定的最小值,这将在下面进一步论述。请注意,在此上下文中术语“优先级(pr1rity) ”仅涉及(并且包括)准许路由器以某种方式区分队列中这两种类型的分组的任何类型的组织架构。例如,这能够包括使用任何适当的存储器、存储空间、队列、群组、划分等。路由器40还包括存储器元件48、处理器50、和 WRED 模块 51。
[0027]使用不同丢弃概率对传输分组进行加权、随机化标记
[0028]图2A的架构与使用相同区分服务优先级内的两个区分服务代码点(DSCP)中的任一者来随机地标记TCP会话的每个传输分组相结合地利用了路由器中的WRED特征。在该特定示例中,两个DSCP代码点是HiDrop和LoDrop。假设路由器中的WRED配置被设置为使得:
[0029]⑴以HiDrop和LoDrop代码点标记的分组共享单一队列;
[0030](ii)HiDrop优先级的分组将在LoDrop优先级的任何分组被丢弃之前被丢弃。这可能例如通过将HiDrop的WRED q_min值设置为显著大于LoDrop的q_min值来实现,如图2A中所示;以及
[0031](iii)对 HiDrop 和 LoDrop 而言 q_max 近似相同。
[0032]在网络中以此配置的情况下,TCP发送方(在示例应用中通常为网络服务器或缓存节点)被设置为随机地并且按照对于该流(或者该流的一部分)固定的比例以HiDrop或LoDrop中的任一者来标记单一 TCP流的每个传输分组。因为单一流的TCP吞吐量是响应于该流的分组丢失率的,所以被标记为HiDrop的分组的比例能够对该流的吞吐量有重大影响。
[0033]举个简单的示例,假设服务器正在发送两个视频片段并且假设在该时刻这两个片段正被发往同一目的地,从而对这两个流而言RTT和路径是相同的。然后,假设服务器将来自第一流的分组标记为HiDrop,但是仅将来自第二流的分组的1/4标记为HiDrop而剩余3/4被标记为LoDrop,按该1: 3比率在HiDrop和LoDrop之间随机选择。因为这两个流共享共同的瓶颈链路,并且由于被标记为LoDrop的分组将总是必然不会被丢弃,所以来自第一流的分组应当会经历近似为来自第二流的分组的四倍大的丢弃概率。因为TCP吞吐量通常反比于sqrt(p_dr0p),所以系统预期第二流将具有第一流的吞吐量的两倍。
[0034]请注意,前述简单示例是在具有对架构正常发挥作用而言十分重要的两个额外考虑的情况下构建的,这两个额外考虑为:
[0035]1.共享队列中的流量是TCP友好速率控制(TFRC)流量。(例如,DCCP将运行良好,正如具有TFRC的RTP/UDP);以及
[0036]2.队列中的每个TFRC流应当将其分组中至少某一合理比例的分组标记为HiDrop0
[0037]这两个额外考虑能够确保来自LoDrop的分组将总是必然不会被丢弃。因为流量是TFRC,所以仅丢弃来自每个流的小百分比的分组能够确保链路中的总体吞吐量受到控制。此外,要求每个单独的TFRC流具有最小百分比的HiDrop分组确保每个流的吞吐量可以被约束而不需要从该流丢弃LoDrop分组。
[0038]另外需注意,即使在极少的情况下来自LoDrop优先级的分组会被丢弃,也不会发生任何有害的事情。在发生这种情况的短暂的时间段内可能无法在流间实现预期的带宽份额,但是当该架构被用于支持ABR视频时,给系统目标功能带来的下降可以是相当小的。
[0039]请注意,本文描述的系统并不严格地限制于使用WRED。路由器中任何会导致根据上述(i)项和(ii)项的丢弃行为的技术都将起到良好的作用。因此,正在开发的用于差异化丢弃的新技术必然会利用本公开的教导。
[0040]RTT多样件的补偿
[0041]在经管理的网络内,在所关注的TCP流之间具有有界并且己知范围的RTT值的情况下,使用上述技术来在具有不同往返时间的流之间实现近似公平份额的带宽均衡是可能的。在本公开的示例实现方式中这将如下进行。
[0042]假设在经管理的网络上、并且在所关注的流之间,存在最小RTT时间rtt_min和最大RTT时间rtt_max。请注意,特定TCP流的RTT时间是TCP发送方已知的值(例如,在其TCP栈内)。另外,当TCP流在瓶颈期彼此竞争带宽时,它们通常将近似与它们相应的RTT值呈反比地共享带宽。
[0043]为补偿由不同RTT引入的非均等带宽份额,TCP发送方将以正确的比例设置分组中以HiDrop标记的部分以补偿较长RTT的影响。特别地,并且假设TCP吞吐量相对于RTT和分组丢失率的有利行为:
[0044]1.具有rtt_min (或更小)的RTT的流将使其全部分组被标记为HiDrop。
[0045]2.具有 rtt > rtt_min 的 RTT 的流将使其分组的 f_HiDrop = (rtt_min/rtt)林2的部分被标记为HiDrop而其余被标记为LoDrop。
[0046]假设吐量相对于RTT和分组丢失率的有利行为,无论何时竞争TCP流在瓶颈期竞争时,以上机制应当对于竞争TCP流给出近似相等的吞吐量。而且,在实际场景中,对于RTT多样性的校正可在某种程度上比以上所表明的更复杂。此外,该校正可能不会在宽的RTT值范围内可靠地发挥作用。然而:
[0047]1.对RTT多样性的校正不需要应用于宽的范围。在经管理的网络中,情况可能经常是所关注的流仅源自少数位置并且这些位置相对接近目的地。
[0048]2.没有理由精确地运用上面给出的公式。试探法(Heuristics)可被用于校正例如对于长或短的RTT值的误差,或者甚至对于不同TCP栈的误差。
[0049]3.当该机制被用于管理去往ABR客户端的带宽流时,不一定要能够精确地或者以
当前第2页1 2 3 4 5 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1