用于数据流的快速友好启动的制作方法
【技术领域】
[0001] 本发明描述一种用于分组数据流的方法，其使用分组上的、指示路径上的最长瞬 时队列长度的标记，W便快速增加流速率直至可用容量而不会出现超调(overshoot),而非 通过W低速率启动并且每次往返加倍直到检测到超调为止来探测容量的传统方法。具体来 说，其设及用于基于所指示队列长度的传输速率自适应的方法和装置。
【背景技术】
[0002] 数据源面临运样的困境，即，无论何时其都具有很少或者没有关于有多少容量可 用的信息，但其需要在不造成过度拥塞的情况下尽可能快地发送数据。数据源在每次其启 动新的数据流、每次其在空闲时段之后重新启动，W及每次已经共享同一容量的另一流完 成时都面临运种困境。
[0003] 已经针对TCP提出的系列拥塞控制算法结合了两种形式的运算：一种依赖于拥塞 反馈(闭环控制），另一种是在没有反馈时(开环控制）。针对当前因特网，当发送方具有很少 或没有关于有多少容量可用的信息时，在启动或重新启动流时或者在竞争流结束时必须使 用开环控制。
[0004] 例如，大多数TCP算法使用相同的"慢启动（S1OW-Stadr算法来W指数方式增加 发送速率，通过每次往返加倍发送速率来探测更多容量，直到接收方反馈其已经检测到作 为拥塞的第一信号的丢失为止。发送方在其发送速率超出可用容量之后的一个往返时间接 收到该反馈。到其接收到该信号的时候，其将已经W超过可用容量两倍的速率进行发送。 [000引在TCP算法内使用被称作拥塞窗口的概念来控制其速率。该窗口是可W发送超过 已经被确认的数据的数据量。利用知之甚少或未获知的可用容量(开环)很难证明一个拥塞 窗口是否好于另一个-任何行为在某些情况下可能是安全的，而在其它情况下却可能是不 安全的。因特网标准表示，流应当W不大于4380B(在W太网上，3个全尺寸分组(full-sized packets))的窗口启动，而当前用10个分组的窗口进行试验。在没有关于实际可用容量的更 好的信息(开环控制)时，按惯例来设置像运些的数字W控制流的行为。同样，没有特别的原 因为何TCP在其开启阶段每次往返加倍其窗口。加倍无疑匹配TCP算法的另一部分在其闭环 (或"拥塞避免"）阶段所进行的减半。然而，选择用于加倍和减半的数字二完全是任意的。 [0006]该加倍并不总是与非TCP业务良好地交互作用。考虑在其它方面为空的IGb/s链路 上的进行中的低速率(例如，64kb/s)恒定比特率语音流的情况。进一步想象大TCP流在具有 10个1500B分组的初始拥塞窗口和200ms的往返时间的同一链路上启动。为发现有多少容量 可用，该流维持每次往返加倍其窗口，直到(在差不多十一次往返之后)其窗口为每轮16667 个分组(1化/s),并且在第十二次往返期间的某一点，其将也已充满该IGb/s链路的缓冲区。 我们将假定已经对该缓冲区进行尺寸调整W采取全窗口分组（16667)，因此，对于发送方来 说，其将进行另一轮来充满该缓冲区，在该点处，其窗口将已增长至33333个分组(2Gb/s)。 一轮后，其将得到检测丢弃的第一反馈，该反馈将暗示早于其的一往返超出了可用容量和 缓冲区两者，因而，发送方将减半其窗口。然而，就在该点之前，其窗口将已达到66667个分 组，表示四倍链路速率或4Gb/s。在该下一轮中大约50 %的分组(33333个分组)将被丢弃。如 果针对单个流对缓冲区恰当地进行尺寸调整，那么，分组的运种巨量丢失是最好的情况。即 使针对多个流(假定25个)对缓冲区进行尺寸调整，仍必须放弃20000个分组（16667*(1 + 1/ ^T25) =20000)。
[0007] 在该示例中，TCP已经进行了 12次往返(在该情况下，超过2秒钟）来寻找其恰当的 操作速率。而且，当TCP丢弃如此大量的分组时，其可能花费长时间来恢复，有时导致更多秒 钟的中断（由于长暂停或主机用于释放大量缓冲区而花费的时间，已经报告100秒钟 阳aO引）。在该过程中，语音流还很可能因至少50%的语音分组在该时段期间被丢弃而中断 达至少200ms，并且通常更长。
[0008] 运表明在流开启期间存在两个问题:i)在流稳定在针对可用容量的恰当速率上之 前的较长的时间，和ii)在最近启动流发现其已经增加其速率超出该可用容量(超调）之前， 针对本身和其它流的非常大量的丢失损坏。
[0009] 运些问题不是仅出现在新流开启时。一个非常类似的情况出现在流已经空闲一定 时间，然后重新启动时。当流在空闲之后重新启动时，对于其来说，不足W记住当其最后活 动时可用容量是什么，因为当时，其它业务可能已经开始使用同一容量，或者正使用同一容 量的流可能已经结束，留下比早先更多的可用容量。
[0010] 运些问题甚至不是仅出现在流启动或重新启动时。如果两个流共享同一容量，贝U 它们都将不断地缓慢尝试使用更多容量，故意导致常规缓冲区溢出和丢失。当任一流检测 到丢失时，其通过减速来进行响应。所有的增加和所有的减小的结果导致每一个流平均消 耗一定比例的容量。然而，当一个流结束时，另一个流从未被明确告知更多的容量可用。其 仅仅继续缓慢增加，在其最终消耗另一个流释放的所有容量之前可能是非常长的时间。
[0011] 近来，已经设计了诸如CubicTCP(立方TCP)的新TCP算法，其更快速捜寻最近可用 容量。然而，它们发现新容量越快，它们在达到可用容量的新限制与稍后检测到它们已经达 到该限制的往返之间的超调量就越多。
[0012] 随着因特网链路的容量增加，和流使用的比特率增加，太慢增加与太多超调量之 间的运种开环控制困境逐步地变得更严重。
[0013] 在现有技术中，已知在分组网络中用于信令拥塞（即，构建队列）的许多不同方法， 例如，主动队列管理(AQM)技术(例如，360、1?61、？1、？16、(：〇〇61)可^被配置成在检测到队列 即将开始增长时但在该队列变满之前丢弃一定比例的分组。所有AQM算法随着队列增长得 更长而丢弃更多的分组。
[0014] 主动队列管理算法可W被设置成放弃标记有更低服务级别、或者标记为合同外 (out-of-con化act)的更大比例的业务。例如，加权随机早期检测[WRED]确定是否利用RED AQM算法来丢弃到达分组，但用于该算法的参数取决于每一个到达分组上标记的服务级别。 [001引显式拥塞通知化CN)[RFC3168]借助于IP报头(无论IPV4(图2)还是IPv6(图3))中 的两比特ECN字段在TCP/IP网络中运送拥塞信号。在介绍ECN之前，运两个比特按两种类型 的IP报头呈现，但总是设置成零。因此，如果运些比特都是零，则队列管理进程假定该分组 来自终端系统上的传输协议，其不理解该ECN协议，因而，其仅使用丢弃，而非ECN，来用信号 通知拥塞。
[0016]图4示出了IPv4或IPv6中的两个ECN比特的全部四种组合的含义。如果任一个比特 为一，则其告知队列管理进程，该分组来自有ECN能力的传输化CT)，即，发送方和接收方二 者都将ECN标记（W及丢弃)理解为拥塞信号。
[0017] 当队列管理进程检测到拥塞时(针对具有非零ECN字段的分组），其将ECN字段设置 成经历拥塞(CE)码点。在接收到运种标记的分组后，TCP接收方在其发送的分组的TCP报头 中设置经历拥塞回复化CE)标志，W确认其已经接收到该数据分组。至少出于其速率控制的 目的，标准TCP源解释ECE反馈，犹如该分组已经被丢弃。但是，当然，其不必重传该ECN标记 的分组。
[0018] 丢弃和拥塞信号不是互斥信号，并且，能够实现ECN的流具有检测并响应于两个信 号的可能性。
[0019]ECN标准[RFC316引刻意将相同的含义指配给具有一个比特集(01和10)的两个ECN码点。它们都意指该传输有ECN能力化CT)，并且如果需要对它们进行区分，则将它们分别称 作ECT(I)和ECT(O)。本发明是要使针对创新的新途径的范围能够对将来要提出的运些字段 进行区分。
[0020]许多作者已经提出了用于缓解快速启动数据流与超调之间的困境的技术。该研究 因为其在损害另一半的情况下仅改进了一半的困境，或者因为该提议被认为在部署上不切 实际而基本上仍保持相对模糊。而且，大部分研究者已经集中于拥塞控制的闭环阶段，或许 未意识到随着速率增加，开环阶段即将成为主要问题。运些提议都落入两个组中，i)提议单 独改变终端系统的那些，和ii)提议改变终端系统和排队算法两者的那些。
[0021 ]Pacedstart(步测启动）阳U03]提议单独改变发送方，W监测在TCP慢启动期间当 按列发送时在分组之间添加缓冲区的排队延迟。然后，其步测在随后的轮中发送的分组。运 避免了TCP的超调，但其花费比TCP的慢启动甚至更长的时间来达到可用容量。
[0022] Hybridslow-start(混合慢启动）阳a08]保持TCP的慢启动算法无变化，但发送方 在其将开始超调的点，而非在其已经超调之后的一往返时间，来尝试停止加倍拥塞窗口。其 通过监测每一轮中的早期确认之间的延迟的增加，W及通过监测每一个完整确认列的持续 时间何时接近该往返时间来进行。尽管混合慢启动被部署在Linux中，但由于与其提升性能 相比往往似乎其降低性能更多而通常将其关闭。运是因为有时其过早结束开启阶段，并然 后花费较长时间来达到可用容量。
[0023] CapStart[Cac09]与HSS类似地，使用分组-对（packet-pair)延迟测量，W便提早 结束慢启动(有限慢启动）。然而，如果其测量到瓶颈很可能在发送方而非在网络中，则其通 过恢复到经典慢启动来获得极大增益，在该情况下，将没有大的丢失事件(episode)要避 免。为了保持易处理，利用化的试验本身仅限于没有交叉业务的情况。
[0024] Liu等人[Liu07]研究出，如果每一个流简单地发送全部其在第一往返时间期间步 测出的数据，那么影响会是什么(称作JumpStad)。如果确认报告丢失，或者如果第一确认 在仍有数据发送时返回，则该算法移动进入TCP的标准重传和拥塞避免行为。作者监测当前 因特网流并且发现它们中仅大约7.4%包括多于发送方在现有标准行为下无论如何都将立 即发送的=个分组。该论文不确定的是，因特网的边缘是否将会应付该7.4%的流将造成的 非常高的丢失率(因为它们表示因特网上的非常大比例的字节）。
[0025] 尽管[Liu07]主要是关于仅针对发送方的变化，但其提到发送方可W通过交换机 和路由器将超过在第一轮中允许的=个的任何分组标记为符合优先放弃条件。运将保护竞 争流免于任何超调，但其需要在所有潜在的瓶颈缓冲区处启用优先放弃。下面描述的其余 方案还需要修改终端系统和网络缓冲区两者。
[0026] Fast-Start(快速启动）[化dman98]在开启期间使用来自先前连接的可能失去时 效的拥塞窗口。然而，为了补偿，其发送具有更高丢弃优先级（即，更可能被丢弃)的分组。其 还改进TCP的丢失处理W应付更高的丢失概率。更高的丢弃概率被如下定义："路由器实现 简单分组丢弃优先级机制。其基于1比特优先级字段来区分分组。当其缓冲区充满并且其需 要丢弃分组时，如果有的话，其首先挑选低优先级分组。由于快速启动分组被指配低优先 级，因此该算法确保过于积极的快速启动不会造成(非快速启动)其它连接的分组被丢弃"。
[0027] TCP-Peach[Akyildiz01]还使用具有低优先级的、被标记成通过网络处理的探测 分组，W便在卫星网络环境中检测备用容量。
[0028] 快速启动设及针对用于发送方的TCP的修改，W明确地询问路径上的所有路由器 其应当W什么比特率启动。快速启动将不会有效工作，除非每一个路由器都已经被升级成 参与到信令中。而且快速启动没有向非IP感知的下层交换机发送信号的方法，并且其需要 所有源被网络信任，W随后按网络请求它们发送的速率来发送。
[0029] 美国专利7,680,038(Gourlay)公开了一种用于最优化带宽使用同时控制延迟的 方法。Gourlay教导在"探测模式"与"稳定模式"之间切换。在探测模式下，带宽估计模块通 过发送"突发"分组来确定用于连接的可用宽度，并且提高(rampup)(或增加)可用带宽，直 到接收到指示分组丢失的确认分组为止，并且针对下一突发，减小可用带宽。在确定估计可 用带宽之后，W该估计可用带宽的一部分发出数据。
[0030] 针对两个有ECN能力的传输化CT)码点存在一些已知的另选用途。
[0031] 一种想法是，使用ECT(I)值来信号通知不拥塞化CT(O))与拥塞(CE)之间的中间程 度拥塞。该想法已经在被称作预拥塞通知的方法的一个变型例中标准化(PCN[Rrc5670])。 PCN使用虚拟队列，其实际上不是队列；而是表示如果缓冲区比真实缓冲区耗尽更慢地耗尽 则将形成的队列的长度的数字。PCN的一个变型例使用两个虚拟队列，一个队列被设置成W 比另一队列更慢的速率耗尽。当更慢的虚拟队列充满时，其利用ECT(I)码点标记分组，而当 更快的虚拟队列充满时，其利用CE码点标记分组。该PCN方法未被标准化为用作针对终端系 统的信号，然而，仅在网络内，虚拟队列已经被用于向终端系统算法发送信号，例如，Hi曲 化ilisation叫traLowLatency(高利用率超低延迟）（皿]X)[Alizadehl2]。
[0032] 在D.Satoh等人的"SinglePCNthresholdmarkingbyusingPCNbaseline encodingforbothadmissionandterminationcontrols"附录D[I]中，描述了用于标 记表示逻辑链路的瞬时利用率的分组的比例的机制。该逻辑链路的利用率通过标记当虚拟 队列为非空时到达的每一个分组的ECN字段来发送信号。标记分组中的比特相对于所有比 特的比例则表示瞬时利用率，但该表示仅针对中间到达时间的Poisson分布精确。此外， Satoh等人的技术在准