[发明专利]用于在分组网络中处理分组的方法、节点和分组网络

说明书

用于在分组网络中处理分组的方法、节点和分组网络。一种方法和装置，其用于如果缓冲队列中已经存在具有相同的第一状态值的分组，则在所述分组到达缓存器时将分组标签状态值从第一值改变为不同的值。在端节点处接收到的分组中的标签状态值(112)的序列用于确定分组网络中的缓存器的队列长度。之后，端节点可以改变其发送速率以适应缓存器的速率。

技术领域

本发明描述了一种重标记分组的方式，从而表示分组网络中的缓存器处的队列的长度，并且其具体地涉及了一种用于基于所示队列长度的传输速率自适应的方法和装置。

背景技术

每当数据源几乎没有或没有与可用容量的数量有关的信息时，它将会面临两难的处境，但是它需要尽快地发送数据，而不引起过度拥塞。每当数据源开始新的数据流时，每当数据源在空闲期后重新开始时，以及每当另一流完成已经共享相同容量时，它将会面临两难的处境。

针对TCP已经提出的一族拥塞控制算法结合了二种操作形式：一种依赖于拥塞反馈(闭环控制)，而另一种在没有反馈(开环控制)时。在当前的因特网上，当发送器几乎没有或没有与可用容量的数量有关的信息时，开环控制必须在流的开始或重新开始时或在竞争流的结束时使用。

例如，大多数TCP算法采用相同的“慢启动”算法，以指数方式增加发送速率，通过加倍每个往返行程的发送速率来探测更多容量，直到接收器反馈到它已检测到作为拥塞的第一信号的丢失。发送器在其发送速率超过可用容量之后的一次往返行程时间，接收此反馈。当它接收到该信号时，它将正以可用容量两倍以上的速率发送。

在TCP算法内使用称为拥塞窗口的概念，以控制其速率。所述窗口是能够以超过已被确认的数据来发送的数据量。在几乎或根本不知道可用容量(开环)的情况下，难以争论是否一个拥塞窗口好于另一个，任何特性都可能在某些情况下是安全的，而在其它情况下是不安全的。因特网标准称流应当以不超过4380B(通过以太网的3个全尺寸分组)的窗口开始，且一般以10个分组的窗口进行试验。当没有与实际可用容量(开环控制)有关的更好信息时，这些数量由惯例设定，以控制流的特性。同样地，为什么TCP在其起始阶段期间的每次往返行程会加倍其窗口是没有特殊理由的。加倍必定匹配在其闭环(或“拥塞避免”)阶段期间，TCP算法的另一部分所做的减半。然而，加倍和减半两者的选择数目是相当随意的。

此加倍并非始终与非TCP业务很好地相互作用。考虑到低速率(例如64kb/s)常数-比特-速率语音流正在另一空1Gb/s链路上进行的情况。进一步想象到大的TCP流在具有十个1500B分组的初始拥塞窗口和往返行程时间200ms的相同链路上开始。为了发现可用容量的数量，流每次往返行程时加倍其窗口直到在几乎11个往返行程之后，其窗口为每次往返16,666个分组(1Gb/s)。在下一往返期间，它将在获得检测暗示其前一往返行程超过可用容量的丢弃的第一反馈之前加倍到2Gb/s。该下一往返(16,666个分组)中将丢弃大约50％的分组。如果缓存器尺寸合适，则分组的该巨大丢失是最佳情形。

在本示例中，TCP已经用去11个往返行程时间(在这种情况下超过2秒)以发现其正确的操作速率。此外，当TCP丢弃该大量分组时，它可以需要花很长时间进行恢复，有时导致数秒(由于长期超时已经报告了的100秒[Ha08]，或主机释放大量缓冲所需的时间)的中断。在该过程中，由于在这期间内丢弃了至少50％的语音分组，该语音流也可能中断至少200ms且经常更长时间。

这表明在流-启动期间存在两个问题：i)在流稳定在可用容量的正确速率之前的长时间；和ii)在新开始流发现其已经将其速率增加超出可用容量(过冲)之前，对本身及对其它流的特大量丢失损害。

这些问题不仅出现在新流开始时。非常相似的情形发生在流已经空闲一段时间，然后重新开始时。当流在空闲之后重新开始时，它不足以记得上次活动时的可用容量的数量，因为同时其它业务可能已经开始使用相同容量，或者使用相同容量的流可能已经完成，留下远比之前更多的可用容量。