CN101112056B - 对信息进行编码的方法 - Google Patents
对信息进行编码的方法 Download PDFInfo
- Publication number
- CN101112056B CN101112056B CN2006800035358A CN200680003535A CN101112056B CN 101112056 B CN101112056 B CN 101112056B CN 2006800035358 A CN2006800035358 A CN 2006800035358A CN 200680003535 A CN200680003535 A CN 200680003535A CN 101112056 B CN101112056 B CN 101112056B
- Authority
- CN
- China
- Prior art keywords
- ecn
- network
- congested
- message
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Transmission Systems Not Characterized By The Medium Used For Transmission (AREA)
- Selective Calling Equipment (AREA)
- Paper (AREA)
- Flow Control (AREA)
Abstract
本发明涉及网络中的数据控制。用于通过n比特字段对很多小动态值进行编码的方法和设备。以及允许从重复的单个字段中无状态提取单独序列由此一次传达多于一个的信号的方法和设备。
Description
技术领域
本发明主要涉及网络中的数据控制。
如下面将要详细解释的,本发明的优选实施方式涉及对穿过网络的数据所经过的路径的表征,其中各节点表征该路径的局部部分,然后,当数据经过时,所有这些局部特征在所述数据中累积。例如,互联网协议(IP)报头中的生存周期(TTL)字段和显式拥塞通知(ECN)字段以这种方式工作。
背景技术
当前,所有已知形式的路径表征法都将意在收集路径特性的字段初始化为设定的标准值。通常,将在目的地积累的值反馈到源。在共同未决的申请第WO2005/096566号中,我们描述了如下设置的优势:确保这些特性字段其中之一的初始值被设置为当它已经累积了路径信息时,它携带常见的标准化的值到达目的地,此处通过引用并入所述申请的主题。我们将该早先申请中提出的概念称为“Re-feedback(再反馈)”,该术语表示“接收器处规范化”反馈的思想(和“经典”或“传统”的反馈相对,在上下文中,该“经典”或“传统”的反馈认为是“源处规范化”反馈)。从目的地到源的反馈随后可用于在未来发送数据时连续地纠正目的地值中的任意错误。主要的优点在于数据有效地携带了其本身下游路径的预测,该预测可为沿着传输路径的在线设备(in-line equipment)所用。
尽管re-feedback带来很多优点,但如果可以发现一种通过逐增配置(incremental deployment)将它引入到当前网络的方法,它将变得更有用。具体而言,携带路径特性的通信因基于re-feedback而可以识别自身,但在引入re-feedback之前,并不是路径上的中继设备都必须升级。因而,如果一对主机都已经升级,则该主机对可以将它们之间的通信构成为携 带基于再反馈的路径特性。而当它们中的一个或它们二者都没有升级时,经典的反馈仍可继续使用。
如下面将要详细讨论的,本发明的优选实施方式涉及这样的方法,该方法将显式拥塞通知的再反馈引入到现在已经用于拥塞通知的互联网协议中的两个比特中,该方法应不需要更换互联网协议格式并且不与当前ECN标准(IETF RFC3168)相抵触-仅需要改变怎样理解字段的语义即可。简而言之,我们将称本概念为“re-ECN”。
重复数据字段中信息的重迭编码
当前通讯协议已被发展为可以根据给定的一组需求在网络上有效地运送数据。它们都使用相同的结构,该结构包括添加了协议报头的有效载荷数据(中的一些),从而可以提供合适的服务。面对当今全球范围的通讯,标准正文明确地定义了将什么信息放入报头中。因为报头信息会增加通讯开销,所以报头字段通常有很严格大小的极限限制。而且,如果字段在分组或帧中的位置和大小是已知的,则更容易设计传输硬件。因此,希望能够在比信号所需的精度小的协议字段中传达信号(该信号是随时间变化的数)。
此外,一旦协议设计变成了标准,则改变先前约定的字段的长度、属性、意思或用途的灵活性就很小了。然而,随着更多服务的提出,更多的威胁的出现了,再加上其他的原因,需要调整和改变分组报头中携带的信息。所以所设计的以前具有足够长度的字段通常需要在不增加字段大小的情况下而过多地承载新的(多个)意义。
一种已知的技术是将信息散布在协议中重复出现的相同字段上。从而随着时间的流逝,看上去好像允许传达比有限字段大小多的精度比特。
简单地,一个数的同一比特表达的不同部分可以在不同的分组中传送。但是对于解释意义的读取器来说,必须和写入器共享一些内容(“状态”)。例如,假设在8比特字段中传送一个16比特的数。我们必须使用这样的约定,即字段的意义依赖于另一相关序列号是奇数还是偶数(奇数意味着较低的有效位,偶数意味着较高的有效位)。然后,读取 器可以使用序列号1,2;3,4...19,20将成对的字段集合起来以获得整个字段。
然而,当协议意在传送滑动值(moving value)并且处于无状态时,该简单的方法是不起作用的。例如,和IP主机不一样,IP路由器是基于这样的原则设计的,从一个分组到下一分组,永不创建用于记忆分组中的任何值的状态(路由器可以使用从所有分组得出的值创建它们自己的聚集状态变量,例如用于记帐的计数器)。所以,即使路由器仅仅只想发现在多个分组中字段的滑动平均值(无论何种原因),也不能通过单独平均所有的奇数和平均所有的偶数来进行。
例如,在与上述简单的场景相似的情况下,假设通过分别平均{2,1,2,1}和{0.1,0.8,0.1,0.7},求出在序列{2.1,1.8,2.1,1.7}的值的滑动窗口上的滑动平均值。即使这些分组将它们自己识别为奇数和偶数,它们还是需要依次平均。假设较高位次的前两个值无序到达。结果将是序列{2.8,2.1,1.1,1.7}的平均值。如果所有的数都被平均,则这样做是没问题的,但是如果平均值是滑动的,则不行。例如,在该两个值无序到达的情况下,最后三个数的平均值不同。当信号在一个高位数和下一位之间转换时,该简单方法导致错误的体系偏移。
1987年,为了满足跨协议字段的重复实例进行滑动数的无状态编码的需要,DEC发展了一种方法[Jain87],其中该数被反复地向下或向上舍入,向下舍入与向上舍入的比例不断增加了精确度,而且当需要传送的数字滑动时也随之滑动。例如,0.4可以通过单一位序列{1,0,1,0,1}或{1,0,1,0,1,1,0,1,0,1,...}表示。然后,如果该数字变成0.2,则序列将反应出这种变化:{1,0,1,0,1,1,0,1,0,1...1,1,0,1,1}。尽管在准确度上具有随机波动,但使用该技术,没有向上或向下的错误的***偏移。与所述的简单的方法不同,没有分组携带没有意义的信息,除非该无意义信息与另一分组的信息组合可以再构出意义。
如下面将要详细描述的,本发明的优选实施方式建立在这种约定的基础上。
另一现有相关机制是Mannal等提出的PURPLE机制[Mannal2003], 美国专利申请US 2004/190449涉及该机制,它监控TCP报头中CWR标志的发生率以评估较早的往返行程中的端对端拥塞程度。使用标准ECN规范,针对每个拥塞标记(CE,表示“经历拥塞”,位于IP报头中),在所有的确认中发送回复(ECE,“ECN-Echo”标志,位于TCP报头中),直到目的地接收了源已经对于拥塞信号做出行动的确认(CWR“拥塞窗口减小”标志,位于TCP报头中)。这意味着CWR标志将以与CE标记到达目的地相同的比率经过路径上的每个节点传输,具有一个往返行程的延时。Mannal等进一步建议在存储器中将到达任意给定节点的CE标记的比率保存一个往返行程的时间。从节点在一个往返行程以后接收的端到端拥塞信号中,节点可以提取在较早的往返行程的路径上的下游拥塞程度。Mannal等提出使用所述值,与当前上游拥塞信号相组合,以控制拥塞的路由器上自适应队列管理机制的收敛。
在非加密TCP流的情况,该方法给出了很精确的信息。然而,该必要信息在其他通常情况下未必可以获得,例如:
-当使用IPSec时,TCP报头被加密,且它变得不能监控CWR标志的发生率;
-当不使用IPSec而传输协议为UDP(这将是RTP流通信的情况)时,CWR标志也不能被监控。
国际申请WO2004/049649(伦敦大学国王学院)涉及中继设备处的差别标记。它涉及两组分组的相应处理,这两组分组称为“第一部分”和“第二部分”。把网络上消耗较少时间的分组认为是位于第一组中,并比在网络上消耗更多时间的分组更容易被标记,把在网络上消耗了更多时间的分组认为是位于第二组中。这样,取决于分组在网络上消耗的时间,来相应处理被认为是第一组和第二组中的各个分组。
参考文献
[Jain87]R.Jain,K.Ramakrishnan & D.Chiu,″Congestion Avoidancein Computer Networks With a Connectionless Network Layer″,DigitalEquipment Corporation technical report DEC-TR-506(1987).
[Mannal2003]Soenke Mannal,Roman Pletka & Marcel Waldvogel- ″PURPLE:Predictive Active Queue Management Utilizing CongestionInformation″,Proceedings of the 28th Annual IEEE Conference on LocalComputer Networks(LCN),Bonn,October 2003.
针对相关问题的其他现有方法
解决需要向协议报头字段添加新信息或修改它们属性的新协议需求的常用方法是发展新的协议或使用具有可变长度的报头。例如,随着IP的发展,这两种方法都被使用了,其中在IP版本4和6之间,地址字段从32比特增加到128比特。与此同时,任意数目的可选字段可以添加到报头中以***用于处理通信的其他信息。
相关问题的一个现有相关机制是ECN时间随机数(ECN nonce)[savage99,Ely01],它涉及IP中的ECN字段。以后将要注意本发明的特定优选实施方式也涉及该字段。而且,在某种程度上,可以认为所述两种方法的动机在以下方面相似:防止在ECN字段的传送中的欺骗。使用拥塞信令,确保拥塞信号不被终端(所述终端希望以比拥塞过程允许的速率高的速率发送或接收数据)隐藏是极为优选的。ECN时间随机数仅允许数据源检查接收器是否正在行骗,而围绕“再反馈”概念建立的较宽的动机框架可以确保路径上的源、接收器或各种网络中任意一个都不能或有动机相互欺骗。以后将变得更加清楚的是,确保再反馈可配置将解决比使用ECN时间随机数可以解决的欺骗问题更宽范围的欺骗问题。ECN时间随机数机制由IETF作为信息RFC出版[RFC3540],但是并不在当前标准轨迹中。
互联网协议报头
简要地参照图6,根据互联网协议的当前版本IPv4,与数据包相关的报头包括指示其版本的第一个4比特字段。第二字段是4比特“互联网报头长度”(IHL)字段,指示IPv4报头中的32比特字的数目。接下来的8比特被分配给“差分服务”字段,包含6位差分服务代码点(DSCP)和位于第14和15比特的2比特“ECN”(显式拥塞通知)字段。DSCP允许规定当数据包经过网络时它将被怎样处理(即,低延时、高优先级等)。ECN字段在拥塞源处随机地设置为:根据一系列分组,目的地可以推断 分组经过的路径的拥塞程度。接下来的16比特IPv4字段8比特字节地定义了整个数据包大小,包括报头和数据。最小长度的数据包为20个字节而最大长度的数据包是65535字节。
接下来的字段是16比特“标识”字段。该字段主要用于原始IP数据包的片段的唯一识别。已经提议该字段可用于其他目的,例如用于向数据包添加分组跟踪信息。随后是3位“标志”字段,用于控制或识别片段。此后跟随13位“片段偏移字段”,它允许接收器判定原始IP数据包中特定片段的位置。
接下来的字段是8比特“生存周期”(TTL)字段,它的目的是防止数据包在网络中持续(例如,在循环中往返)。历史上,TTL字段以秒限定数据包的寿命,但它已经变成“跳数”字段,试图以跨越较大距离的跳维持原始意思,使得它们本身作为多个跳出现。该值可以初始为255。数据包经过的每个分组交换机(路由器)使该TTL字段减一(在与长距离链接的接口处可能更多)。如果TTL字段在到达目的地之前为零,该分组不再被分组交换机转发,并因此被丢弃。
接下来是8比特协议字段。该字段限定了IP数据包的数据部分中使用的下一个协议。互联网地址指派机构(Internet Assigned NumbersAuthority)维持有协议号列表。公共协议包括ICMP、TCP和UDP。
IPv4数据包报头中接下来的字段是16比特“校验和”字段。IPv4数据包报头中的一些值可以在各分组交换机跳处变化,使得校验和在它通过网络的路径上可能需要调整。校验和之后分别跟随32比特“源地址”和32比特“目标地址”字段。
额外的报头字段(称为“选项”)可以跟随在目标地址字段之后,但这些并不常用。
ECN字段
IP中ECN字段的概念可以追溯到上述“DECbit”方案,其也在ATM和帧中继中出现。在IP中,ECN包括8比特差别服务字段的末端的两个比特,得出4种可能的代码点(code-point),这些代码点在RFC3168[RFC3168]中标准化。参照下面所附表1示出了这些代码点。
ECN代码点
代码点. | 意义 | 标识 |
00 | 非ECN,能够传输 | 非ECT |
01 | ECN,能够传输 | ECT(1) |
10 | ECN,能够传输 | ECT(0) |
11 | 经历拥塞 | CE |
表1
前三个代码点在分组传输的起点处由发送器设置,而最后一个(CE)留给中继设备设置以指示该分组经历拥塞。如果源还不支持ECN标准,它将发送通常为缺省的清洁ECN字段(非ECT)。如果它理解ECN,但在连接开始的协商之后,判定另一终端并不理解ECN,它也使ECN字段清洁(非ECT)。如果非ECT分组在拥挤期间到达IP中继设备,则它被概率性地丢失,如果ECT分组到达拥挤的中继设备,则CE字段被概率地设置。这种行为允许ECN的逐增配置,如果终端之一并没有被升级以理解ECN,则回到在拥塞过程中丢失分组的较早行为。
具有CE字段设置的分组的比例代表了范围在[0,1]之间的拥塞程度。这样,CE字段用于从中继设备向接收器传送信号(随时间变化的拥塞程度)。如果在任一传输路径上存在多于一个的拥塞中继设备,则它们的信号相组合以给出该路径上的累计拥塞。例如,如果分组流经一个用CE标记了5%的分组的中继设备以及另一个用CE标记了10%的分组的中继设备,由于组合概率,接收器将在一系列分组中看到100%-(100%-5%)(100%-10%)=14.5%的CE标记。这种组合形式是经过深思熟虑的,因为拥塞信号代表能力耗尽的概率,所以多个拥塞信号应象多个概率组合时那样被组合。实际上,互联网路径大多数时间在1-2%以下的拥塞程度操作。
用于IP的ECN标准允许发送器设置两个等同值的任意之一以指示ECN能力:ECT(0)或ECT(1)。尽管ECN时间随机数并没有标准化为ECN,但在该标准中提供了经过深思熟虑的这样的选择:当源选择使用ECN时间随机数时,允许源使用ECN时间随机数。但是这两个ECT代码点的其他用途也被尽可能地正视,例如,一种用途是用于多点传输(本发明的实施方式利用了CET值的这种选择提供的灵活性)。该ECN时间随机 数如下工作。
发送器以伪随机未偏置二进制序列发送具有ECT(0)或ECT(1)的各分组。在连接开始时,发送器保持该序列的和,将这两个ECT值分别处理为二进制0和1。实际上,该方案仅需要发送器维持该和的最低有效位。这样,如果发送的每个新的二进制ECT值是X,则可以使用逻辑异或函数维持该和S:
接收器将也保存该和。
接收器必须反馈各接收的分组是否已经被标记了CE(实际上该标准允许同时针对多个分组进行反馈,但是其很复杂,在本文中也不重要)。为此目的,ECN标准[RFC3168]在TCP报头中引入了一个二进制字段(经历拥塞回复或ECE)。ECN时间随机数方案[RFC3540]为接收器在TCP报头中引入了另一二进制标志(时间随机数和(NS)),以同样反馈其新计算出时间随机数和。只要没有分组被标记了CE,则发送器和接收器都能为一系列无空缺的分组维持相同的时间随机数和。因为TCP确保所有丢失的分组都被再次传输,而再次传输会修补序列中的任何空缺,因而整个流将无空缺地行进。
在中继设备由于拥塞而用CE标记了分组时,则接收器不能猜出发送器最初是使用ECT(0)还是使用ECT(1)发送它的。如果诚实的接收器接收了被标记了CE的分组,它将发送ECE反馈,且发送器和接收器都将在下一分组中重新启动(归零)它们的时间随机数和。如果恶意接收器试图通过不回送响应CE标记的ECE而否认拥塞的存在,它还必须反馈更新的时间随机数和。但是,因为不知道发送器是使用ECT(0)还是使用ECT(1)来更新发送器的时间随机数和,因而接收器仅具有50%的机会来使时间随机数和正确。接收器试图抑制的拥塞反馈越多,一半的时间它将使时间随机数和错误。一旦发送器检查到不正确的时间随机数和,通过在未来的分组中设置非ECT而不使用ECN或采取一些其他的制裁,甚至拒绝发送进一步的数据。
可以看出ECN时间随机数允许发送器检测行为不端的接收器。但这 仅当发送器本身希望遵循自发拥塞控制以及希望向不遵循的接收器进行制裁时有用。在90年代后期的环境中,ECN时间随机数被认为是有用的,在该时期的环境中,大多数数据由大的合作站点(要么是web服务器,要么是内容流站点)发送的。可以期望这些站点会希望维持一种声誉,用于管制互联网拥塞控制规范。但当前80%的通信是点对点的,因而这种乐观的假设不再成立。本发明允许再反馈可配置,使得网络可以管制它们自己的拥塞规范。
参考文献
[Savage99]Stefan Savage,Neal Cardwell,David Wetherall and TomAnderson,″TCP Congestion Control with a Misbehaving Receiver,″In:Computer Communication Review 29(5)pp.71--78(October,1999).
[RFC3168]K.K.Ramakrishnan,Sally Floyd and David Black,″TheAddition of Explicit Congestion Notification(ECN)to IP,″InternetEngineering Task Force Request for comments RFC3168,URL:http://www.ietf.org/rfc/rfc3168.txt(September,2001)
[Ely01]David Ely,Neil Spring,David Wetherall,Stefan Savage andTom Anderson,″Robust Congestion Signaling″In:Proc.IEEE InternationalConference on Network Protocols(ICNP′01)(November,2001).
[RFC3540]Neil Spring,David Wetherall and David Ely,″RobustExplicit Congestion Notification(ECN)Signaling with Nonces″InternetEngineering Task Force Request for comments RFC3540,URL:http://www.ietf.org/rfcs/rfc3540.txt(June,2003)(Status:informational)
发明内容
根据本发明,提供了一种方法,该方法使用经过网络中多个节点的多个报文对信息进行编码,各所述报文具有与之相关的包括一个或更多个字段的报头,各报头的至少一个所选部分提供至少三个代码点;所述方法包括指派与第一比例的报文相关的报头的所选部分的第一组代码点中的代码点;以及指派与第二比例的报文相关的报头的所选部分的第二 组代码点中的代码点;其特征在于
所述第一比例依赖于第一网络特性而判定;
所述第二比例依赖于第二网络特性而判定;以及
所述第一网络特性和第二网络特性中的至少一个不依赖于所述网络特性中的另一个网络特性变化。
本发明的优选实施方式涉及在n比特字段上对很多小动态值进行编码的方法。
本发明的优选实施方式允许从重复的单个字段无状态地提取单独的序列,由此同时传送多于一个的信号,且允许通过各种算法组合使每个结果重迭以传送更多信息。为了说明这点,我们将优势逐渐增多的解决方案的进展考虑为怎样获得上述目的,在此之后,将详细描述根据本发明的一个优选实施方式的方案。为方便起见,我们将该方案称为“re-ECN”。
在根据本发明的方法涉及IP实现时,应当理解“报文”一般是IP分组。因为ECN目前仅用于IP,因而这一般是与优选的“re-ECN”实施方式相关的情况,但应当理解,例如,在未来,报文不必是与所有网络相关的分组。
应当理解根据当前优选实施方式,所述字段是现有2位二进制字段(ECN字段),这样它允许4个代码点,但是本发明的其他实施方式也是可行的,其中假设字段具有至少3个代码点,字段可具有不同位数。这样可以预见字段是1位的三重字段。在字段提供多于3个代码点(例如,3位二进制字段,提供8个代码点)时,由于本发明的目的,两个或更多的代码点可以被认为或处理为等同物,这种情况它们可以被考虑成“代码点组”。可能会认为这些实施方式在关于它们可用的代码点的使用方面是“低效”的,但是应当注意它们可以提供一些另选的或附加的优点。
还应当理解,根据另一当前优选实施方式,报头的所选部分不必严格地对应于报头中一个名为“字段”的部分,而是可以包括从与各报文相关的报头中选出的邻近比特子集。另一些实施方式甚至可以使用非邻近比特子集。另一当前优选实施方式使用现有ECN字段的两位,并与当 前IP报头中的“第48比特”相组合,这样这三个比特总共提供8种可能的代码点。如下将要更详细解释的,在这些另选方案中使用IP报头中的额外的比特时,它具有这样的优点:在源和网络节点的处理可以简化。
再次参见Mannal等提出的PURPLE机制[Mannal2003]和相应的美国专利申请,应当注意本发明的实施方式不同于现有技术,例如尤其由于这一事实,仅需在一种类型的报头(在一个层中可存取,例如,IP或网络层)中采取行动以对涉及这两种不同特性的信息进行编码,这与Mannal方法中的情况相对,在Mannal方法中,对仅可借助两个不同层(网络层和传输层)存取的两种不同类型的报头(IP报头和TCP报头)采取行动。这样,本发明的实施方式避免了Mannal方法的缺点,并且除了支持IPSec的使用之外,还支持其他传输协议的使用。
可能的解决方案的进展
“再反馈”的优点源于分组中代表预知的下游拥塞的拥塞信号。参考再反馈的概念,可以认为下面的可能的解决方案是目标在于实现再反馈需求的机制。
可能的解决方案#1
如果来自于接收器的确认流的新近反馈显示出路径上具有3%的拥塞,一个简单的方法是发送器在2%的分组中设置经历拥塞的代码点(CE),且2%的拥塞中继设备从2%的分组中去除CE。但一般将证明这是不实际的。只要中继设备希望发送这2%的信号,在到达的标记了CE的分组被清除之前,它必须等待大约50个左右的未标记的分组经过。
可能的解决方案#2
较好的另选方案是发送器交替ECT(0)和CE,但是发送比50%约少2%的CE,使用ECT(0)代替它们。换句话说,标记~48%的CE和~52%的ECT(0)。则在发现可使用CE标记的ECT(0)之前,中继设备可能仅需要平均等待约一个分组。
此处我们将引入一些符号。我们使用uj表示路径上节点j处CE的比率。并且沿着路径,发送器具有索引j=0且接收机具有索引j=n,它们之间的中继设备使用索引{1,2,...j,...n-1}。而且,网络中任一节点j处的下 游路径拥塞程度由ρj表示,所以ρ0将表示整个路径的拥塞,有时我们将简单地缩写为ρ。
所以,对于这种解决方案,节点j的下游路径拥塞将是:
ρj≈50%-uj。
如果源保存它发送CE的比率u0,可以通过减去接收器返回的比率un得出路径拥塞率。但是因为当前路由器不管CE是否已经被设置都标记CE(假设已经提及了所需的组合概率),这种解决方案不能逐增配置。所以它们都必须立刻升级。
可能的解决方案#3
另一较好的第三另选方案是源仍然交替CE和ECT(0),但是发送约比50%少2%的一半的CE(仍然连续我们的场景,其中新近路径拥塞ρ为2%)。换句话说,标记~49%的CE和~51%的ECT(0)。则假设路由器标记CE而不管它是否已经被标记,则约2%的一半的ECT(0)分组将获得CE标记,使CE的比例从49%增加到50%。一般地,如果新近路径拥塞是ρ0,标记标准化的恒定目标率是uz=50%,则源将以比率u0标记CE,其中:
1-(1-u0)(1-ρ0)=uz
例如,对于ρ=2% =0.48979
≈49%
如果网络中任意节点j的CE标记率为uj,则该节点下游拥塞ρj可以由下面的比率预知:
ρj=1-(1-uz)/(1-uj)
然而,这种方案平分了ECN的响应(约一半的标记应用于已经被标记的分组),因为像ECN这样的二进制方案传送低程度的拥塞已经很慢(在低程度变成高程度之前,给出的通知不足),这是不理想的。而且,所有上述方案需要发送器使用CE初始化一些分组,这在当前ECN标准中是不允许的,使后向兼容性复杂化。
根据一个优选实施方式的解决方案:“re-ECN”
为了解决上述问题中的一些或全部,我们提出了ECN的ECT代码点的新的用途来实现再反馈,称为re-ECN。和往常一样,非ECT分组将被丢失而不是被标记。但是,对于所有其他的分组,我们定义了有效的虚拟报头字段h。我们将路径的任意节点j处的hj的值定义为经过该节点的CE代码点的比率uj和ECT(0)代码点的速率zj之间的差,即:
hj=uj-zj (1)
根据再反馈布置,一旦发送器接收到了表征路径拥塞的反馈,它布置该虚拟报头的起始值h0,使得该虚拟报头将在目的地达到共同的数据hz。一般地,通过假设从最新的反馈之后路径拥塞保持不变完成这点。对于re-ECN,我们建议的该产业应该标准化:
hz=0
为了遵循当前ECN标准,我们不希望发送器使用CE初始化任意分组。所以u0=0。则,为了使目的地的虚拟报头归零,发送器将在这样的比例的分组上设置ECT(0):
un≤1/2:z0=un/(1-un) (2)
un>1/2: =1,
可以根据已由TCP提供的un的连续的反馈来推导该比例。将在以后表示公式为何如此。
而且,我们示出,在分组中到达路径的任意节点j的虚拟报头hj足以使该节点得出下游路径拥塞的预测:
ρj=1-1/(1-hj) (3)
如果路径拥塞度低,hj<<1,将在以后示出该公式近似于
ρj≈-hj (3a)
≈zj-uj
换句话说,对于较低程度的路径拥塞,节点可以将下游拥塞近似为虚拟报头的简单的值-ECT(0)和CE代码点比率之间的差,这样避免了每个分组的区分操作,否则将使用比数据路径中所需的更多的处理器循环。这种近似导致中继设备低估下游拥塞。所以使用这种近似的策略器是稍微许可的,这通常是优选的。如果精确度是非常重要的,当然不 需使用这种近似。
实际上,如果路径拥塞度低,则发送器使用的用于判定设置多少ECT(0)的公式还具有简单的近似
z0=un/(1-un)
≈un (2a)
换句话说,源将ECT(1)的比率设置为与回复经历了拥塞(ECE)的确认的比例相同。否则它将设置ECT(0)。再次说明,它将永不设置CE,这遵循当前ECN标准。
然而,可以不使用比乘法更复杂的运算来实现确切功能(且如果指数加权滑动平均值(EWMA)权重是2的倍数,甚至仅寄存器移位)。
参考图1,图示的横轴表示经过网络间路径上索引为{0,...j,...n}的节点。纵轴表示当分组流经过示例性路径时不同ECN代码点的发生率。当然,该比率可以不断变化,但是图中示出了一个瞬间的平均比率,好像拥塞是静止的一样。每个区域基于下面一个累积,使得总和始终为1。黑色阴影区域表示由于ECN路由器的拥塞-从当前行为不变,累计经过该路径的经历拥塞(CE)的标记。中间的图中,所示的CE的最终比率反馈到源,所述源大约发送相同比例的ECT(0)。
右手边的图示出了如何从信号流中解码下游路径拥塞。在路径上的任意节点j,如果CE的发生率uj(黑色)从ECT(0)的比率Zj(中间图中的白色)中减去,可以得出下游路径拥塞(条纹)。
上述实施方式使用ECT(0)代码点以发送所述流的路径上端到端拥塞程度的信号,以最小化IP报头中使用的比特数。如果这种需要不是普遍的,具有类似效果的简单的另选方案是使用ECN代码点之外的比特来运送端到端拥塞信号,例如第48比特。该另选实施方案在IP报头中使用更多的比特,但具有在源和网络节点处简化处理的优点:因为在ECN代码点设置为“经历拥塞”时并不重新标记第48比特,因而不需要调整从目的地接收的ECE信号。
特定re-ECN实施方式
再反馈概念-其中网络中的反馈在接收器而不是发送器与其参考数 据匹配-并不被认为已经在早先讨论的我们共同未决的申请之前公开。因此,一种协议机制,例如能够实现再反馈能力而不需要抵触现有协议标准的re-ECN,在其权利方面是独特的。然而,如下所述,本发明的范围不限于这些优选实施方式。
Re-ECN的一般化
再次参照ECN时间随机数,ECN时间随机数由发送器使用,以将其注入到分组流中的信号与接收器反馈的信号进行比较。ECN时间随机数并不用于将任何信号从一方传送到另一方。本发明的优选实施方式使用“Re-ECN”概念以从网络节点的路径向源和其他网络节点(尤其是上游的这些节点)传送信号(代表路径拥塞)。
一方面,ECN时间随机数对从最近的拥塞事件开始到以当前分组结束的一个ECT代码点的发生率的和进行编码。另一方面,re-ECN使用两个代码点的发生率对两个信号进行编码。Re-ECN然后通过减法组合这两个信号。
尽管ECN时间随机数使用两个代码点,在拥塞事件之间的一段时间中,一个代码点总是限制为另一个的补数。其他ECN代码点独立地用于不同的目的。所以ECN时间随机数仅可以对一个信号进行编码。因为re-ECN同时使用三个代码点,可以创建两个独立的信号,第三个是所述其他两个的和的补数。这样通过创建多于一个独立的信号来区分re-ECN。然后,编码方案可以使用两个信号之间的算术关系-不可能仅使用一个信号。
其他的编码方案可以使用代码点的发生率(尽管除了ECN时间随机数,我们不能在文献中发现任意一种)。但是坚信没有人使用多于一个代码点的比率,而不使用这些比率之间的关系。
实际上,通过对两个独立的信号进行编码,使用re-ECN的本发明的优选实施方式仅使用1.5个比特(即,可以从两个比特中获得的4种选项中的3种),就能够同时将三个潜在有用的指标发送到路径上的节点j:
uj,j的拥塞上游
-hj/(1-hj)≈-hj,j的拥塞下游
zj/(1-hj)≈zj,j的上游和下游的整个路径拥塞
如已经解释过的,再反馈可用于向上游在线设备提供频繁的、可信的信息,所述信息预测携带该信息的各分组的下游路径。这允许网络管制源是否正确地响应了它们的路径上的变化的特性,尤其是拥塞变化。
Re-ECN的优点包括这一事实:它允许实现再反馈,与现有技术相比,其自身在对拥塞响应的管制方面得到改善。从这方面而言,使用re-ECN的本发明的优选实施方式可用于改善ECN时间随机数。Re-ECN使得网络得以管制发送器,即使发送器正与接收器通信。ECN时间随机数仅使发送器管制接收器而不能使网络管制任何东西。
通过重迭不同信息到相同字段,使用re-ECN的本发明的优选实施重新使用现有协议字段,由此使有限的信息空间更加有用。
此外,使用re-ECN的本发明的优选实施方式能够实现下面三个特征中的一个或更多个,故意这样设计以便于逐增配置:
中继设备不改变:中继设备在拥塞过程标记分组,对于这点,re-ECN和ECN没有区别。如果情况并非如此,则终端将需要假设所有的中继设备使用re-ECN或它们都不使用re-ECN。否则,唯一另选方案是为每种类型的信号提供拥塞字段,并且以某种方式在目的地组合它们。因而,终端可以逐增配置re-ECN,且只要re-ECN发送器发现它与re-ECN接收器通讯,它们可以使用re-ECN,而不管路径上的中继设备是否已经升级,因为不需要升级。
高拥塞时出现宿流(legacy flow):可能会觉得对ECT(0)和ECT(1)之间的哪一个用于下游路径指标的选择是任意的。但是我们特意选择ECT(0)。特定实施方式的特殊目的在于,网络能够使用re-ECN来管制来自混合了非-ECN-可行、经典-ECN-可行和re-ECN可行主机的通信。当前,网络根本不能管制拥塞响应。Re-ECN给予网络以信息,使得管制变为可能。但不是只管制已经升级为re-ECN的主机,我们管制所有的流,就像它们使用re-ECN一样。然后,我们可以以这种方式安排管制:随着时间流逝,宿流逐渐被扼杀,而最初非常宽容地处理re-ECN流,但是最终只有re-ECN流将不受损害地经过策略器。
ECN标准建议:如果源仅使用一个ECT代码点,它将使用ECT(0)。如果使用ECN时间随机数,ECT(0)和ECT(1)的比率必须相等。我们知道,除了多点传输之外,还没有提出ECT(1)的其他用途,但是多点传输的用途还未执行。因此,不使用re-ECN的所有的源将发送不少于ECT(1)的ECT(0):
对于非-re-ECN z0≥1/2.
对于re-ECN,如果z0≥1/2;公式(2) un≥1/3
这种高度拥塞是不常见的,所以通常,如果un<1/3
对于re-ECN z0<1/2
换句话说,对于任意ρ<1/3的特定路径,如果源必须在使用和不使用re-ECN之间选择,不使用re-ECN的z0(以及任意下游点的Zj)将高于使用re-ECN的情况。因此,假设无论是否使用re-ECN,uj都相等,则在不使用re-ECN的情况,公式(1)中的下游拥塞的re-ECN定义zj-uj将更高。
导致吞吐量的显著衰减的再反馈的激励框架越宽,下游拥塞越被高估。但是低估导致吞吐量的突然下落。所以我们特意选择ECT(0)用于路径指标,使得不使用re-ECN的源在我们像它们使用re-ECN一样对其进行处理时,确保将高估下游拥塞。
所以,如果策略器通过假设任意源正使用re-ECN宣布下游路径拥塞来抑制源(即使它不这样做),则不使用re-ECN的源将是有缺点的,但是并不是灾难性的。因此,re-ECN策略器可以在互联网的入口处被初始地配置,使得它们对re-ECN非常宽容,但是对经典ECN流则非常严厉。随着时间的流逝,策略器管制可以更加严厉,使得没有升级到re-ECN的落后者逐渐经历更多的抑制。
只要路径拥塞峰值高于1/3,使用时间随机数的经典ECN源将低估下游拥塞,因此具有承受更少的丢失惩罚的危险。然而,当拥塞大于1/3时,没有升级的丢失的通信将很少,但是仍足以给出升级的进一步的激励。
没有附加的延迟信令拥塞:相对于经典ECN,路由器同样向终端发 送拥塞信号,且因此,当前动态不发生变化。在CE标记之间,经典ECN允许任意一个ECT代码点,所以我们仅限制两者之间的比率。
附图说明
现在将参照附图详细地描述本发明的优选实施方式,在附图中:
图1是“re-ECN”概念的示意性表示;
图2示出了与根据本发明的第一优选实施方式的实现相关的端到端结构,该实施方式着重于拥塞通知;
图3是标准TCP套接字的概要;
图4是再反馈TCP套接字的概要;
图5示出了现有保障型QoS综合器(GQS)的结构;
图6示出了互联网协议IPv4的当前版本的报头格式;
图7示出了标准回送方法(echo discipline)以及
图8示出了比图2所示的更一般的端到端结构。
具体实施方式
在描述可以执行本发明的优选实施方式之前,提供了一些公式的推导的讨论,这些公式将在后面引用。此后,将参考三个特定实现实例描述本发明的优选实施方式。
公式推导
Re-ECN的优选或理想的实现取决于用于定义从网络到源和从源到网络的信号比率的公式。所以,首先,我们推导在上述发明内容中使用的公式。
如上所述,我们将路径上任意节点j处的hj值定义为经过该字节的CE代码点的比率uj和ECT(0)代码点比率zj的差:
hj=uj-zj (1)
我们的目标是在目的地使该报头归零,即确保目的地ECT(0)的比率为:
目标:zn=un
如果发送器发送比例为z0的ECT(0)分组以在目的地达到zn,则一些分组将被路径上的中继设备所标记,将它们转换成CE。为了遵循当前ECN标准,我们不希望发送器用CE初始化任何分组。所以u0=0并且因此unz0比例的分组将以ECT(0)开始但以CE结束。所以在任意节点j,被保持设置为ECT(0)的分组的比率将是
zj=(1-uj)z0 (4)
或在目的地
zn=(1-un)z0
所以,将我们的目标带入上面的公式,发送器将以这样的分组比率设置ECT(0)
z0=zn/(1-un)
=un/(1-un), (2b)
发送器可以根据连续反馈的un推导z0,其中TCP已经提供这些un。
如果任一节点j知道下游的最终CE标记比率un,则它将使用到来的分组的CE标记比率uj得出下游路径拥塞度。
ρj=1-(1-un)/(1-uj)
该公式是拥塞标记被概率化的结果。我们通过将任一节点i的标记概率取为mi来证明它,则在一系列j节点之后,该标记概率为:
uj=1-IIi=0,(j-1)(1-mi)
=1-IIi=0,(n-1)(1-mi)/IIi=0,(j-1)(1-mi)
=1-(1-un)/(l-uj)
经过代换和化简,可以看出用于下游路径拥塞度的该表达式可以归到仅节点j知道的局部变量的项中:
从公式(2b)得出 un=z0/(1+z0)
从公式(4)得出 z0=zj(1-uj)
=1-1/(1-hj). (3)
近似
如果路径拥塞度低,Taylor展开给出了节点j的下游拥塞:
ρj=1-1/(1-hj)
=1-(1+hj+hj 2+...)
hj<<1:≈-hj
类似地,公式(2b)变为
z0=un(1+un+un 2+...)
un<<1:≈un
然而,该第二个近似不是必须的,并且导致发送器低估拥塞,所以我们并不推荐它。
假定较宽的再反馈的激励框架(这超出了本讨论的范围),因为网络可以使用精确形式来评估下游拥塞,源使用公式(2b)的精确形式高估下游路径拥塞是比较安全的。
边界条件
将u和z定义为2比特字段中代码点CE和ECT(0)的发生率,从而将它们大小限制为下面的范围:
u,z ∈[0,1]
以及h =u-z
而且u+z ≤1
根据公式(2b)可知un=z0/(1+z0)
≤1/2
所以,该公式对于z0(ECT(0)的最初比率)必须分段给出:
un≤1/2:z0=un/(1-un) (2)
un>1/2: =1
在固定条件下,当经过路径时,CE的比率从零直至增加到ECT(0)的比率,所以u≤z,暗示h≤0。但是在发送器获得其所需的反馈来增加发送器设置的ECT(0)比率之前,该ECT(0)比率有时可能不足以超过CE标记的瞬间增长。所以在这些瞬态,h可能取自其全范围[-1,1]。拥塞表 示一种概率,因此它将位于[0,1]范围。但是ρ可能在该范围之外,这是因为它仅是下游路径拥塞的一种预示,可能被错误的评估,高估后又低估,所以滑动平均值是有用的。然而,ρ是非线性的,具有预测误差,而h是线性的。因此需要对ρ进行平均。替代性的,下游拥塞的监控者可使用足够长的时间常数测量比率h的滑动平均以平滑它。这使得h位于下面的范围:
h ∈[-1,ε] 0≤ε<<1.
然后使用公式(3),ρ的滑动平均值可以安全地根据h得出:
ρj=1-1/(1-hj)
注意如果ρ>1/2,则re-ECN不能表达下游路径拥塞。这是公式(2)中对z0的限制的结果。然而,CE标记的比率u可以表示拥塞的全部范围[0,1]。所以,为安全起见,un将被源使用,用于拥塞控制(如我们在下面所做的),而h和ρ将仅用于向网络宣布下游拥塞。然后大于50%的下游拥塞将通过基于re-ECN的传输正确地作用,但是高于50%的不变的操作将误导网络认为源正不诚实地低估拥塞。如果较宽的再反馈的激励框架是适当的(本讨论范围之外),则网络将丢失分组。但是如果保持50%的显式拥塞通知,网络将早已丢失了很多的分组。
实现实例#1:使用re-ECN的端到端TCP/IP
端到端结构
一般地,再反馈使得网络能够向数据路径上的各节点通知下游网络的一个或更多个特性指标。这里我们仅集中于拥塞通知。图2示出了再反馈的一般的端到端结构的主要反馈相关功能的结构。中继设备0和源可以是相同的节点。
当产生新流的第一个分组时,源初始化再反馈信号。然后,开始三步反馈循环:
-各中继设备对指标mi的贡献与反馈信号hi组合
-目的地处的再反馈信号hn从目的地回送回源,
-源更新后续分组中的再反馈信号h0的初始值。
而且路径上的任意节点(包括各终端主机)可以监控该指标的值,例如,用于调节源的数据速率或用于控制路由节点处流经的通信。
尽管积聚在网络层执行,但所有其他功能可以在传输层执行。
这里我们着重于再反馈对TCP速率控制的应用。其他传输协议也将需要类似的功能以更好地利用再反馈,尽管具体执行方式将有所不同。
图3勾画了源处的半连接的标准TCP套接字。图4示出了再反馈TCP套接字具体不同之处。为简单起见,我们忽略与另一半连接相关的所有信息交换,也没有考虑其建立(set-up)与拆除(tear-down)。
当前TCP实现
在标准TCP中,两个信息流异步地发生。右手侧,应用程序向套接字发送数据,该套接字向速率控制程序请求发送(RTS)多个比特(大小)。如果合适,则速率控制引擎准许发送(CTS)并返回用于该TCP分组的序列号以及标准ECN使用的拥塞窗口减少(CWR)标志。当准许发送时,TCP分组器使用IP有效载荷、ECN字段的值(设置为ECT)以及另一IP标志(如果相关的话),形成对IP的相关请求。
另一信息流由到达的来自TCP连接目的地的确认触发。ACK读取器将提取与该半连接相关的信息,即经历拥塞的回复比特(ECE)和确认号。速率控制程序然后可以调整所述拥塞窗口(cwnd)。两个信息流必须同步的唯一时间是该分组器请求该速率控制程序(RTS/CTS循环)的时候。
Re-ECN的TCP变形例
使用再反馈,信息流的一般循环保持与使用TCP的情况类似。唯一的补充是ACK读取器之后的路径捕获函数,它的作用是维持值z0,该值是路径上最近拥塞的表征,用于判断ECT(0)以什么比率在外发分组中设置。
当应用程序请求该TCP套接字发送数据时,几乎每一件事情都与标准TCP相同。唯一不同之处在于速率控制线程将把CTS信号发送到路径捕获函数,使得它判断出在下一分组中设置哪个ECT的值。
初始化
ECT(0)的比率z0由源设置,并取决于从接收器反馈的ECE的比率un,通过公式(2)可得:
un≤1/2:z0=un/(1-un)
un>1/2: =1
在流的开始的时候没有任何反馈,un可以初始地使用对前面可能路径的一些估值进行设置。但是假设没有新路径最近的知识可以获得,安全的政策是初始化un=1,这暗示z0=1。即,将使用ECT(0)设置发送流的所有初始分组。
组合
每个中继设备表征其局部拥塞为mi,然后使用概率mi将进入的分组标记为CE。例如,mi可以是由服务所述分组的外出接口利用当前指数加权滑动平均序列长度使用RED算法产生的概率ρa。换句话说,中继设备对CE代码点的标记与当今没有什么不同。
所以,在各中继设备处,外发分组的CE标记的比率将取决于进入的CE比率以及由组合函数计算的当前拥塞
ui+1=1-(1-ui)(1-mi)
因此,ECT(0)代码点的发生率将修改为
zi+1=zi(1-mi)
所以虚拟报头字段将修改为:
hi+1=ui+1-zi+1
回复
参考图7,可以以下面两种方式中的一种完成回复:
1.对于标准ECN标记,CE分组由具有经历拥塞回复(ECE)标志设置的TCP应答所确认。该ECE标志将一直被设置,直到目的地从源接收了具有CWR比特设置的分组为止。实际上,ECE标志将被设置大约一个往返行程时间。
2.另选的解决方案是仅在返回的第一应答中回复标记。
图7示出了第一种情况:发送器发送6个分组(普通箭头),它们在 收条中得到确认(虚箭头)。左边示出了各分组中的CWR位的值,而右边示出了每个应答中的ECE位的值。首先CWR和ECE设置为零。当拥塞标记发生(ECN字段设置为“CE”代码点)时,发送器开始向回发送ECE设置为1的所有应答。一旦接收器获取了ECE=1的应答,将唤起它的拥塞窗口(因此此时仅发送两个分组)并将CWR=1通知给接收器。一旦接收器接收CWR=1,它将ECE重新设置为零。所述整个顺序将被解释为用于下述机制目的的单个回复。
监控
监控节点j的下游拥塞需要从数据流的两个代码点CE和ECT(0)的比率的差得出hj=uj-zj。取决于监控目的,可能需要单独的值以用于不同的通信粒度,例如,针对各个流(例如,TCP源需要的流),针对到达目的地IP地址或子网的所有的分组,针对类的所有分组,或简单地针对所有的分组。无论监控粒度怎样选择,最有效的监控算法将是指数加权滑动平均法,平滑常数ψ判断该值的平滑程度如何(值越小,越平滑)。对于每个ECT分组,算法如下:
如果CE 则F=1
如果ECT(0)则F=-1
如果ECT(1)则F=0
hj←ψF+(1-ψ)hj
由公式(3)ρj=1-1/(1-hj)
更新
TCP应答中用于回复所经历的拥塞的ECE标记将用于直接得出该TCP比率反应,因为它们遵循ECN标准规范。
该re-ECN的主要区别是需要设置在发送的分组中ECT(0)的比率z0。图4示出了路径捕获函数维持un的滑动值,我们将在下面描述。然后,在分组器具有新的数据要发送时,它向速率控制器发送一个发送请求(RTS)。一旦拥塞窗口足以允许新的数据被发送,则速率控制器询问路径捕获函数是否将设置ECT(0)。路径捕获函数向分组器发送准许发送(CTS)响应,分组器使用公式(2)的实现方案判断将要设置哪个ECT代 码点。
下面提出了自同步算法。主要机制包括在将要发送的下一分组重新***为ECT(0)代码点的ECE标记,我们将该分组称之为第一ECT(0)分组。而且,如果平均每N个分组接收到ECE回复,则校正机制包括在每N-1个ECE回复中在“第二”ECT(0)分组中***额外的ECT(0)代码点。
因为N的期望平均值是1/m,所以这有效地执行了公式(2),且公式(2)给出了ECT(0)分组将要被发送的频率为1/(N-1)。第一ECT(0)分组的频率仅为1/N。第二ECT(0)分组的频率是1/(N×(N-1)),这正确地补偿了差异。
下面是实现该机制的伪代码,其中
-ECT0_buffer跟踪仍需要发送的分组的数目;
-i跟踪从最后一个第一ECE回复开始的经确认的分组的数目;
-N是两个ECE回复之间分组的平均数目的估计;
-R是用于从最后一个第二ECT(0)分组开始发送的第一ECT(0)分组的数目的计数器。
当接收到新的ACK时,
.i++
.如果(“ECE字段被设置为1”)
.....增加(ECT0_buffer)
.....N=EWNA(N,i)
.....i=0
.....R++
.....如果R≥(N-1)
..........增加(ECT0_buffer)
..........R=0
当速率控制模块准许分组发送时:
.如果ECT0_buffer>0
.....ECT0--
.....设置ECT(0)
.否则
.....设置ECT(1)
公式(2)的一个另选实现方案在下面的代码中给出:
.如果un≤(1-un).rand[0,1]
.....设置ECT(1)
.否则
.....设置ECT(0)
其中un是到达源的、包含经历拥塞回复(ECE)的TCP应答的数目。当接收到应答时,ACK读取器告知路径捕获函数。然后指数加权滑动平均值(EWMA)un取决于ECE是否被标记而更新,
如果ECE{un←(1-α)un+α}
则{un←(1-α)un}
“ack”然后被传递到速率控制器。应注意,当ack到达速率控制器时,它通常增加拥塞窗口,允许分组器发送一些更多的片段。这是为什么我们在路径捕获函数更新un之后,将ack传递到速率控制器的原因,使得任一新片段的ECT代码点将考虑随ack到达的最新路径信息。
几个往返行程时间之前发送的分组将对EWMA没有贡献,因为它们提供的路径知识是过时的。因此,EWMA平滑权重α将优选地各个分组地再次计算,以确保时间常数反映了行程中分组的数目f,f可以由源TCP计算,我们假设:
α=1/(1+f)
(1+f)使用允许考虑刚到达的ack。严格来说,f是导致当前ack的分组被发送时行程中的分组的数目。
对于这两种实现方案,只要TCP算法的任一部分认为发生了丢弃,无论丢弃是通过三个完全相同的应答、过时或其他方式发生,路径捕获函数都将行动,好像已经接收了具有ECE设置的最后的应答一样。
作为更新机制的一个另选方案,ECN回复可以立即被再次***TCP流中,作为ECT[1],这实现了公式(2a)。这可以通过在每次接收到具有ECE比特设置的应答时通过增加计数器完成。只要计数器为空,则CTS 应答将ECN字段设置为ECT[0],只要计数器不为空,就将ECN设置为ECT[1]。后一种情况,计数器立即减1。在不同于ECE位的其他方法检测到拥塞事件时,计数器也将增加。
实现实例#2:使用re-ECN的边到边保障型QoS综合器
保障型QoS综合器(没有re-ECN)
保障型QoS综合器是一种技术,它使得网络运营商能够为经过单个或互连的IP网络的无弹性的通信提供逐流保障型服务质量(QoS),简单而不会有过度供应的成本。保障型QoS综合器(GQS)已经在很多BT互连报告中描述,但是还没有一个发表。
GOS使用三种标准互连网协议,但是它们都具有与其原始设计不同的结构:
·使用预留信号协议,例如RSVP[RFC2205],但和原始集成服务结构[RFC1633]不同,它是一种可扩展结构;
·使用差分服务代码点(DSCP)[RFC2474],但是没有DiffServ结构[RFC2475]中服务水平协议处理的复杂度;
·使用显式拥塞通知(ECN)[RFC3168],但不是其原始的端到端拥塞控制结构。
在以上三种情况中,我们没有抵触标准,因为我们避免使用的结构仅是信息性的-它是标准化的协议。
图5示出了环绕很多核心网域并形成GOS域的GQS网关的“围墙”(ring-fence)。该图示出了每个网络被分割成两个逻辑上独立的层。这表示了带宽预留保护的通信量-保障型(G),和不受保护的通信量-非保障型(N)之间的区别。GQS网关不需要环内的容量在两种类型的通信之间被硬区分。各种类型的通信量的比率可以根据需要灵活设置,但是一旦接受了保障型流,则指派给它的容量就被确保,不使用关于环中区域内的路由器的任何预留机制。
示出了一些数据流进入或离开各网关,各网关代表了其附属的接入网络。为清楚起见,没有示出这些流经过核心,但一个流除外,沿该流的长度都被突出显示。在***,在每个网关的接入网络端,解决方案是 传统的,使用为接入网络选择的任一种QoS技术(例如,带宽代理或IntServ)。
GQS网关应该位于网络中的一些点处,在这些点处,在统计上来说足以进行通信的多路传输,使得添加一个流不会使***从零拥塞到过载。网关的环之外,由于较低的通讯量,可以使用较不可扩展的预留技术。GQS仅意在用于核心网络(也包括较大的接入网络)的可扩展性。
怎样在接入网络中处理端到端QoS预留信号是不重要的,因为GQS可以处理很多模型,但是为了使描述具体,我们假设预留协议(RSVP)用作端到端控制路径机制。具体而言,围墙处的GQS网关能够截取和处理RSVP QoS报文,而环中区域内元件不能这样做(即,RSVP报文对于这些元件是不透明的,因此默默地作为内部的数据包处理)。
端到端处理模式是RSVP中传统的一种。数据发送器通过宣布其要发送的流的规格,并且每一跳将其地址传递给下一跳(未示出),而沿着数据路径准备路由器。但是在GQS区域内,因为仅有网关截取RSVP报文,因而RSVP将整个区域处理为单个跳。因为单个RSVP跳可以故意包含多个运营商,因而即使不同运营商之间的边界也不处理信号化的报文。
在到达数据目的地之后,信号响应沿着相同的一组路由器(图5中以虚箭头表示)返回。同样,因为所有的区域内的路由器不能看见RSVP,所以整个区域表现为单个预留跳,出口网关直接发送其响应到入口网关早先给出的地址。如果端到端RSVP信号交换彻底完成,则预留状态被添加到每个网关,使得数据路径处理可以开始。
应用于所述流的各种数据路径处理步骤由带圈的数字表示,在接入网络设备中,步骤(1)表示数据的传统管制以在预留中保持它。GQS网关通过仅允许与接受的预留相匹配的数据被标有选出来代表“保障”(在图中以“G”指示)的差分服务代码点来提供保障。不在预留之下的任意通信,包括超过了为之预留的比特率的通信,在允许进入该区域之前,通过管制机制,被再分类(即,降级)成另一类型的服务,由“N”指示(步骤2)。这只是标准通讯管制和再分类-与DiffServ中使用的没有什 么不同,只不过所有保障的通信还被标记为ECN-可行(否则它将被丢弃,而不是在拥塞发生事件中由内部路由器标记)。
应注意,与DiffServ结构中的不同,环中路由器上的很多容量并不配置给保障的优先级。且新的通信契约(预留)的接受并不依赖于是否已经为该类配置了足够的容量的计算。
在所有区域内元件的数据路径上,保障的通信量给出比其他类更严格的优先级,并在缓冲器太满时允许抢占共享缓冲器中其他通信量的位置。如果任一区域内路由器经历拥塞,则它将标记所有分组的一部分,使其携带ECN行进(步骤3)。应注意,ECN标记并不对区域内路由器没有察觉的流做任何动作。一旦到达出口GQS网关,从各入口网关到达的通信中的ECN标记的部分被单独计量(4)。只要至少一个预留是有效的,各出口GQS网关维持该部分的滑动平均值,用于各上游GQS网关的通信量的聚集。在RSVP的情况下,在做出了预留请求时,则使用RSVP的用于运送不透明的目标的能力在对该请求的响应上驮载(piggy-backed)拥塞报告。这样,拥塞报告反馈到入口,在那里准许接入可以得到控制。
通过所述拥塞指标判定上游准许接入控制(步骤2)。因为原先的MBAC方案被限制为单个节点,这种结构被称为分布式基于测量的准许接入控制(DMBAC)。如果报告的关于通往相关的下游网关的路径的通信的ECN比例超过一个固定阈值,则入口网关将拒绝新的预留请求。
如果新的请求到达没有适当的其他有效预留的网关对之间,则入口网关经过环向出口网关发送足够的探测分组以确立平行于下游预留路径报文的路径的ECN部分。当其返回时,预留请求获得拥塞报告,如有必要,执行等待,并将它反馈到入口网关,在那里准许进入控制像以前一样继续。
使用re-ECN的保障型QoS综合器
为简单起见我们称该方案为re-GQS。
Re-GQS与GQS在除了一个方面之外的所有方面都相同。预留信号是相同的,且它们携带的拥塞报告也相同。唯一的不同在于跨GQS区域 使用re-ECN而不使用ECN。优势在于,下游拥塞指标可以在域边界之间测量,而使用ECN仅能测量上游拥塞。一旦在各域边界之间可以测量下游拥塞,则各下游邻居可以使用它来管制其上游邻居的行为。所以,如果上游网络接受了太多的预留而不管下游网络中的拥塞如何,则在该网络在边界处可以测量高程度的下游拥塞。
激励上游网络不欺骗的一个简单的方法是根据它们导致的下游拥塞的比率来对它们收费。一旦re-ECN使得下游拥塞在域间边界处可见,则可用简单的计数器计算在计费周期(例如一个月)经过该边界的下游拥塞的程度。然后,下游邻居可以根据所述计数器依比例向其上游邻居收费。这提供了正确的激励从而防止了欺骗,但是原先没有机制可以允许在正确方向中进行这种收费。原先,因为拥塞通知在下游方向中增加,仅上游邻居能向其下游邻居收费。在激励上游网络行动方面,这种支付方向是错误的方法。
当使用上面的TCP实例时,与ECN相同地使用re-ECN,只不过当入口网关启动ECT时,它使用公式(2)以比率z0设置ECT(0)代码点,该比率反映了目的地出现的拥塞u0。否则,它将设置ECT(1)。其他方面,re-ECN和ECN一样。区域内路由器标记经历拥塞(CE)和以前没有什么区别。因为GQS只关心网关之间的拥塞-边对边,而非端到端-用于re-GQS目的,目的地是出口GQS网关。由出口网关附属到预留请求的拥塞报告记录了相对于保障的类的全部分组的CE分组的滑动平均值。所以,当入口网关发送预留请求时,它接收一个携带拥塞报告的响应,该报告已经有效地包含CE比例(fraction)un。这有效地等同于TCP发送器的更新函数的这样的部分,该部分根据TCP应答维持ECE的滑动平均值。但在GQS的情况下,出口网关维持该滑动平均值,并且在预留请求返回到入口时,仅发送当前值。实际上,RSVP刷新预留请求(一般每30秒)。如果在一定时间之后,节点没有看见刷新,它假设预留已经被清除,只是清除的报文丢失了,所以它清除预留。所以出口网关可以使用至少每次刷新后的最新的滑动平均值更新拥塞报告。而且,如果多个预留正在一对网关之间进行,则每个预留请求和每次刷新允许出口使用最 新的滑动平均值更新入口。相同的滑动平均与所述对之间的所有预留相关,所以任意一个预留可以使用为相同网关对之间的另一个报告的滑动平均值。
针对报告所来自的各出口网关的IP地址,入口网关在一列表中保存最新的拥塞报告un。每次更新的报告从出口网关到达时,它简单地替代前一个报告。入口网关还针对有效流预留的列表中的各流保存下一个下游跳的IP地址。因为从出口到入口的RSVP应答携带它来自(出口网关)的下游RSVP跳的IP地址,所以它可以完成这点。
当各分组到达时,入口网关必须总是在其有效预留流的列表中查询所述分组的流标识符。这样做是为了发现哪个令牌桶策略应该负责该分组。同时,它可以在所述列表的相同的行中查询下一RSVP跳的IP地址。然后,可以在有效出口网关列表中查询该IP地址以发现源于该网关的最新的拥塞报告un。一旦具有un,它可以运行与TCP发送器所做的相同的算法,以判断设置哪个ECT代码:
如果un≤(1-un)rand[0,1]{设置ECT(1)}
否则{设置ECT(0)},
然后网关之间的保障的通信量将携带虚拟报头h,它是CE标记比率u和ECT(0)比率z之间的差。所以路径上的监控器可以以与上面在TCP实例中的监控函数下已经描述的完全相同的方法判断下游拥塞ρ。
为了每月一次地在域间边界j处执行下游拥塞收费(该收费是用于向GQS引入re-ECN的原始激励),下面的简单的机制将是足够的。应该维持三个单独的计数器,用于经过该边界的标记了CE、ECT(0)和ECT(1)的分组的容量(以字节计)。我们将前面的两个称为Uj和Zj,且我们将它们的和称为Vj,它是所有ECN可行通信量。
则根据公式(1):hj=(Uj-Zj)/Vj.
从公式(3)可以得出:ρj=1-1/(1-hj)
所以如果网络之间的拥塞容量的同意的费用是λ,则上游邻居支付给下游的每月一次的费用将简化为:
λρjVj
实现实例#3:一般化的重迭的编码
考虑一个长度为N的多比特字段,该字段传送可以取R个值中的任一个的信息。这留下M=2N-R个未使用的值,我们可以再次使用这些未使用的值来传送额外信息。
在各分组中,流在源处被初始化,且可以在各中继设备处更新(例如下游的中继设备可能被减少),这构成了所述该字段的主要用途。因此中间节点可以监控在该字段中被编码的值的动态演变。
我们建议使用一些不用的M值作为警告(或者报警)代码点,使得,一旦需要,使用该警告代码点重写该字段(比较ECN中的CE字段)。中间节点可以监控该点并且计算警告频率以合成另一路径特征。
Re-ECN由N=2得出,警告被编码为CE。通过在一定比例数量的分组中将ECN字段设置为ECT(0),源对端到端的拥塞指标进行编码(通过近似回复由源发信号告知的任意ECE标志),而其他的分组被设置成ECT(1)。中间节点可以监控作为ECT(0)与ECT(*)的比例的端到端的拥塞指标。它也可以监控上游拥塞(CE警告的比例)。下游拥塞的评估是所述两者的差。
对于小的低警告频率,这运行非常良好(比较:低比率的拥塞标记)。
参考图8,我们考虑Re-ECN的一般化以及图2中描述的机制。该机制可以涉及表示拥塞的指标,或者可以涉及其他类型的指标。使用的字段可以仅具有2位,例如ECN字段,或者具有很多比特N,其中,字段的主要用途是从源和/或网络节点向下游节点和/或目的地传送信息。为此目的,用一组N比特代码点Sp表示字段。当基数card(Sp)<N时,可以再次使用从源和/或网络节点到下游节点和/或目的地的额外的代码点。我们定义警告代码点组为Sa={A1,...Ak},且k+card(Sp)<N。警告Aj具有优于任何警告Ai(其中i<j)以及且任何初始代码点的优先级。换句话说,网络节点可以使用更高优先级的警告代码点重写初始代码点或者警告代码点。
参照图8,各节点处的功能如下:
-源初始化或者更新所述源在它发送的分组的报头的字段中设置的 值。
-网络节点或中继设备可以添加它们的局部贡献,或者,使它们的局部贡献与所述指标相组合。
-源或任一网络节点可以使用更高优先级的代码点重写报头字段。
-任一节点可以监控初始字段的值和/或警告代码点的存在和/或频率。
-目的地回复该报头字段的值,并可以结合其自身贡献,或者将它重写为更高优先级的代码点。
如上所述,本发明的实施方式能够实现一种机制的设计,允许单个多位字段的多种用途,既用于向流的路径上的节点传输最初的连续信息,也用于传输以异常代码点的频率中编码的二次信息。
参考文献
[RFC2205]Braden(Ed.),R.,L.Zhang,S.Berson,S.Herzog and S.Jamin,″Resource ReSerVation Protocol(RSVP)---Version 1 FunctionalSpecification,″Internet Engineering Task Force Request for comments 2205URL:http://www.ietf.org/rfc/rfc2205.txt(Sep 1997)
[RFC1633]R.Braden,D.Clark,and S.Shenker.Integrated services inthe Internet architecture:an overview.Request for comments 1633,InternetEngineering Task Force,URL:rfc1633.txt,June 1994.
[RFC2474]K.Nichols,S.Blake,F.Baker,and D.Black.Definition ofthe differentiated services field(DS field)in the IPv4 and IPv6 headers.Request for comments 2474,Internet Engineering Task Force,URL:rfc2474.txt,December 1998.
[RFC2475]S.Blake,D.Black,M.Carlson,E.Davies,Z.Wang and W.Weiss″An Architecture for Differentiated Services″Internet EngineeringTask Force Request for comments 2475,URL:http://www.ietf.org/rfc/rfc2475.txt(Dec 1998)
[RFC3168]K.K.Ramakrishnan,Sally Floyd and David Black,″TheAddition of Explicit Congestion Notification(ECN)to IP,″Internet Engineering Task Force Request for comments RFC3168,URL:http://www.ietf.org/rfc/rfc3168.txt(September,2001)
本发明的优选实施方式的优点的总结
本发明的优选实施方式使较早的再反馈概念可配置于互联网。使较早的再反馈概念可配置在再平衡互联网上的权力平衡方面是很重要的,使得网络运营商可以管制用于容量分配的经济可行的规则。
例如,很多互联网用户仅下载IP话音(VoIP)产品,该产品工作,对拥塞不响应,在拥塞过程中有效地从其他用户窃取容量而不需要支付覆盖峰值负载时间容量所需的费用。对于其他产品,例如交互式视频,情况相同。使用IP话音产品,现在对于一些用户来说,很容易不被察觉地窃取他们所需要的东西,而不用为它买单。
通过允许再反馈概念的实现,本发明的实施方式还将应对洪水式攻击的责任推回了允许它们被送出的网络,并且允许其他服务供应商自动扼杀来自持续充满网络容量的机器(例如被蠕虫接管的主机)的链接。
经济学者一般同意:拥塞信息对于优化网络的使用来说是必须的,且在数据网络中,十分频繁地需要该信息。但是在当前互联网反馈结构中,即使设置了规则以基于拥塞公平地分配容量,它们也将不是可实施的,因为网络运营商不能获取必要的下游拥塞信息。另选地,因此使用了可实施的规则,但这些规则仅仅是下面的指标的不良另选:所有经济学者都同意的可使得真正公平共享容量的指标:下游拥塞。
Claims (26)
1.一种使用经过网络中多个节点的多个报文对信息进行编码的方法,各所述报文具有与之相关的包括一个或更多个字段的报头,各报头的至少一所选部分提供至少三个代码点;所述方法包括指派与第一比例的所述多个报文相关的报头的所选部分的第一组代码点中的代码点;以及指派与第二比例的所述多个报文相关的报头的所选部分的第二组代码点中的代码点;其特征在于
所述第一比例依赖于第一网络特性而判定;
所述第二比例依赖于第二网络特性而判定;以及
所述第一网络特性和第二网络特性中的至少一个不依赖于所述网络特性中的另一个网络特性变化。
2.根据权利要求1所述的方法,其中所述所选部分是一个n比特字段,其中n大于1。
3.根据权利要求2所述的方法,其中所述n比特字段是2比特字段。
4.根据前面权利要求其中任意一个所述的方法,其中所述所选部分包括与各报文相关的报头中的现有字段。
5.根据权利要求4所述的方法,其中所述所选部分包括从与各报文相关的报头中选出的邻接比特子集。
6.根据权利要求4所述的方法,其中所述所选部分包括从与各报文相关的报头中选出的非邻接比特子集。
7.根据权利要求4所述的方法,其中所述所选部分包括拥塞通知字段。
8.根据权利要求7所述的方法,其中所述所选部分包括显式拥塞通知字段。
9.根据权利要求1所述的方法,其中所述信息包括至少一个值。
10.根据权利要求9所述的方法,其中所述网络特性中的至少一个是动态特性。
11.根据权利要求1所述的方法,其中所述第一和第二网络特性是动态特性。
12.根据权利要求1所述的方法,其中所述网络特性中的至少一个涉及所述网络中的拥塞。
13.根据权利要求12所述的方法,其中所述网络特性中的至少一个涉及所述网络中的路径上的端到端拥塞的测量。
14.根据权利要求13所述的方法,其中涉及端到端路径拥塞的所述网络特性就它在与报文经过所述路径的一个往返行程时间对应的时段之后可以变化这种意义上而言是动态的。
15.根据权利要求12所述的方法,其中所述网络特性中的至少一个涉及所述网络中的路径上的上游拥塞的测量。
16.根据权利要求15所述的方法,其中涉及上游拥塞的所述网络特性就它在与报文经过所述路径的一个往返行程时间对应的时段期间可以变化这种意义上而言是动态的。
17.根据权利要求16所述的方法,其中所述所选部分包含显式拥塞通知字段,且其中取决于上游拥塞的所述测量,表示“经历拥塞”的代码点CE被指派给与第一比例的报文相关的报头中的该显式拥塞通知字段。
18.根据权利要求1、8或17所述的方法,该方法还包括以下步骤:响应来自于接收器的所述信息需要更新的报文的指示,改变所述第一比例和第二比例中的至少一个,所述改变步骤包括以下步骤:
从多个随后发送的报文中选择一定比例的报文,所述比例依赖于源于所述接收器的指示的特性;
向所选报文指派代码点,从而导致所述信息被更新。
19.根据权利要求18所述的方法,当该方法从属于权利要求8或17时,其中所述指示包括“经历拥塞”通知,且所述选择步骤包括在收到所述“经历拥塞”通知之后选择报文。
20.根据权利要求18所述的方法,当该方法从属于权利要求8或17时,其中所述指示包括多个“经历拥塞”通知的回复,且所述选择步骤包括:判定在两个连续回复收条之间确认的报文数N的估值,以及为每N-1个确认的报文选择一个报文。
21.根据权利要求20所述的方法,其中所述估值是滑动平均值且所述选择步骤包括:
为每个接收的回复选择一个报文;
以及为每N-1个接收的回复选择一个额外的报文。
22.根据权利要求1所述的方法,其中所述第一组代码点和所述第二组代码点之一或二者包括一个代码点。
23.根据权利要求1所述的方法,该方法用于从重复的单个字段中执行单独序列的无状态提取,由此同时传达多于一个的信号。
24.根据权利要求23所述的方法,该方法还包括通过各种算法组合来重迭每次的结果。
25.根据权利要求18所述的方法,当在经过网络中的多个节点的一个路径上发送报文时,指派代码点的所述步骤中的至少一个由所述网络中的节点执行。
26.根据权利要求18所述的方法,当在经过网络的多个节点的一个路径上转发报文时,指派代码点的所述步骤中的至少一个由所述网络中的节点执行。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0501945A GB0501945D0 (en) | 2005-01-31 | 2005-01-31 | Control of data in a network |
GB0501945.0 | 2005-01-31 | ||
EP05255137 | 2005-08-19 | ||
EP05255137.1 | 2005-08-19 | ||
PCT/GB2006/000330 WO2006079845A1 (en) | 2005-01-31 | 2006-01-31 | Control of data flow in a network |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101112056A CN101112056A (zh) | 2008-01-23 |
CN101112056B true CN101112056B (zh) | 2012-07-18 |
Family
ID=35946719
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2006800035358A Active CN101112056B (zh) | 2005-01-31 | 2006-01-31 | 对信息进行编码的方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US8498210B2 (zh) |
EP (1) | EP1844583B1 (zh) |
CN (1) | CN101112056B (zh) |
AT (1) | ATE452492T1 (zh) |
DE (1) | DE602006011125D1 (zh) |
WO (1) | WO2006079845A1 (zh) |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4739141B2 (ja) * | 2006-02-24 | 2011-08-03 | アラクサラネットワークス株式会社 | リングネットワーク及びマスタノード |
US20080096507A1 (en) * | 2006-10-24 | 2008-04-24 | Esa Erola | System, apparatus and method for creating service accounts and configuring devices for use therewith |
CN1976343B (zh) * | 2006-11-10 | 2010-07-28 | 华为技术有限公司 | 提高传输控制协议数据吞吐量的方法及*** |
US9065888B2 (en) * | 2007-02-16 | 2015-06-23 | Orange | Method for optimizing the routing of communications between a plurality of telephony domains, corresponding signal, device and computer program |
US7760642B2 (en) | 2007-03-12 | 2010-07-20 | Citrix Systems, Inc. | Systems and methods for providing quality of service precedence in TCP congestion control |
US7796510B2 (en) * | 2007-03-12 | 2010-09-14 | Citrix Systems, Inc. | Systems and methods for providing virtual fair queueing of network traffic |
EP2079205A1 (en) * | 2008-01-14 | 2009-07-15 | British Telecmmunications public limited campany | Network characterisation |
US7903562B2 (en) * | 2008-02-05 | 2011-03-08 | Lockheed Martin Corporation | Method and system for congestion control |
EP2101503A1 (en) * | 2008-03-11 | 2009-09-16 | British Telecommunications Public Limited Company | Video coding |
EP2200319A1 (en) | 2008-12-10 | 2010-06-23 | BRITISH TELECOMMUNICATIONS public limited company | Multiplexed video streaming |
EP2219343A1 (en) | 2009-02-12 | 2010-08-18 | BRITISH TELECOMMUNICATIONS public limited company | Modification of explicit congestion notification (ECN) by skipping congestion experienced (CE) events |
EP2219342A1 (en) | 2009-02-12 | 2010-08-18 | BRITISH TELECOMMUNICATIONS public limited company | Bandwidth allocation control in multiple video streaming |
WO2010092323A2 (en) * | 2009-02-12 | 2010-08-19 | British Telecommunications Public Limited Compan | Data transmission |
US8374091B2 (en) * | 2009-03-26 | 2013-02-12 | Empire Technology Development Llc | TCP extension and variants for handling heterogeneous applications |
US8427949B2 (en) * | 2009-08-07 | 2013-04-23 | Future Wei Technologies, Inc. | System and method for adapting a source rate |
CN102035814B (zh) * | 2009-09-30 | 2014-08-27 | 瞻博网络公司 | 通过vpn ipsec隧道确保服务质量 |
US8693320B2 (en) * | 2010-01-11 | 2014-04-08 | Research In Motion Limited | Congestion level indication with explicit congestion notification in communication systems |
US8416690B2 (en) * | 2010-01-11 | 2013-04-09 | Research In Motion Limited | Explicit congestion notification based rate adaptation using binary marking in communication systems |
US9001663B2 (en) * | 2010-02-26 | 2015-04-07 | Microsoft Corporation | Communication transport optimized for data center environment |
US8340126B2 (en) | 2010-06-07 | 2012-12-25 | Lockheed Martin Corporation | Method and apparatus for congestion control |
EP2398194A1 (en) | 2010-06-17 | 2011-12-21 | British Telecommunications Public Limited Company | Monitoring path characterisation information |
US8634297B2 (en) * | 2010-11-01 | 2014-01-21 | Cisco Technology, Inc. | Probing specific customer flow in layer-2 multipath networks |
US8724467B2 (en) * | 2011-02-04 | 2014-05-13 | Cisco Technology, Inc. | System and method for managing congestion in a network environment |
EP2493131A1 (en) * | 2011-02-28 | 2012-08-29 | British Telecommunications Public Limited Company | Obtaining information from data items |
EP2541850A1 (en) | 2011-06-30 | 2013-01-02 | British Telecommunications Public Limited Company | Determining path congestion measures |
EP2727284B1 (en) | 2011-06-30 | 2018-06-06 | British Telecommunications public limited company | Determining path congestion measures |
EP2575303A1 (en) | 2011-09-30 | 2013-04-03 | British Telecommunications Public Limited Company | Determining congestion measures |
CN103999414B (zh) * | 2011-09-30 | 2017-09-08 | 英国电讯有限公司 | 一种归因针对相应用户寄存器的共享资源的拥塞贡献的方法和装置 |
US9042227B2 (en) * | 2012-01-17 | 2015-05-26 | Netapp, Inc. | Systems , methods, and computer program products providing feedback for network congestion management |
EP2723021A1 (en) * | 2012-10-18 | 2014-04-23 | Telefonaktiebolaget L M Ericsson AB (Publ) | A method and an apparatus for determining the presence of a rate limiting mechanism in a network |
US9025458B2 (en) * | 2012-10-23 | 2015-05-05 | Verizon Patent And Licensing Inc. | Reducing congestion of media delivery over a content delivery network |
US9497125B2 (en) * | 2013-07-28 | 2016-11-15 | Mellanox Technologies Ltd. | Congestion control enforcement in a virtualized environment |
US9948565B2 (en) | 2013-08-19 | 2018-04-17 | Instart Logic, Inc. | Method and implementation of zero overhead rate controlled (ZORC) information transmission via digital communication link |
US9648560B2 (en) | 2013-10-16 | 2017-05-09 | At&T Intellectual Property I, L.P. | Utilizing explicit congestion notification for network selection |
US9148814B2 (en) | 2013-10-28 | 2015-09-29 | At&T Intellectual Property I, L.P. | Probe mechanism for discovering explicit congestion notification data |
US9825884B2 (en) | 2013-12-30 | 2017-11-21 | Cavium, Inc. | Protocol independent programmable switch (PIPS) software defined data center networks |
US10587720B2 (en) * | 2014-02-11 | 2020-03-10 | T-Mobile Usa, Inc. | Network aware dynamic content delivery tuning |
US10616380B2 (en) | 2014-06-19 | 2020-04-07 | Cavium, Llc | Method of handling large protocol layers for configurable extraction of layer information and an apparatus thereof |
US9635146B2 (en) | 2014-06-19 | 2017-04-25 | Cavium, Inc. | Method of using bit vectors to allow expansion and collapse of header layers within packets for enabling flexible modifications and an apparatus thereof |
US9923836B1 (en) * | 2014-11-21 | 2018-03-20 | Sprint Spectrum L.P. | Systems and methods for configuring a delay based scheduler for an access node |
US9893835B2 (en) * | 2015-01-16 | 2018-02-13 | Real-Time Innovations, Inc. | Auto-tuning reliability protocol in pub-sub RTPS systems |
US9807024B2 (en) | 2015-06-04 | 2017-10-31 | Mellanox Technologies, Ltd. | Management of data transmission limits for congestion control |
US10009277B2 (en) | 2015-08-04 | 2018-06-26 | Mellanox Technologies Tlv Ltd. | Backward congestion notification in layer-3 networks |
US10237376B2 (en) | 2015-09-29 | 2019-03-19 | Mellanox Technologies, Ltd. | Hardware-based congestion control for TCP traffic |
CN107645478B (zh) * | 2016-07-22 | 2020-12-22 | 阿里巴巴集团控股有限公司 | 网络攻击防御***、方法及装置 |
CN108881056B (zh) * | 2017-05-15 | 2022-02-25 | 华为技术有限公司 | 一种拥塞控制方法、网络设备及其网络接口控制器 |
US10944684B2 (en) * | 2017-05-23 | 2021-03-09 | Cable Television Laboratories, Inc. | Systems and methods for queue protection |
CN113743619B (zh) * | 2020-05-27 | 2023-09-29 | 西交利物浦大学 | 基于关联网络行为的作弊用户识别方法和装置 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1545286A (zh) * | 2003-11-21 | 2004-11-10 | 清华大学 | 基于ecn且带预测验证的拥塞控制方法 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5426640A (en) * | 1992-01-21 | 1995-06-20 | Codex Corporation | Rate-based adaptive congestion control system and method for integrated packet networks |
JP3604615B2 (ja) * | 2000-04-21 | 2004-12-22 | 株式会社東芝 | 通信装置、中継装置および通信制御方法 |
JP2002252640A (ja) * | 2001-02-23 | 2002-09-06 | Fujitsu Ltd | ネットワーク中継装置及び方法並びにシステム |
AU2002343053A1 (en) * | 2001-11-30 | 2003-06-17 | British Telecommunications Public Limited Company | Method of resource control in a wireless network |
ATE311709T1 (de) * | 2002-02-01 | 2005-12-15 | Univ Darmstadt Tech | Verfahren zur bestimmung der verkehrslast in einem kommunikationsnetz mittels datenpaket- markierungen |
US7161904B2 (en) * | 2002-06-04 | 2007-01-09 | Fortinet, Inc. | System and method for hierarchical metering in a virtual router based network switch |
GB2395856A (en) | 2002-11-26 | 2004-06-02 | King S College London | Method for reducing packet congestion at a network node |
US7468947B2 (en) | 2003-03-31 | 2008-12-23 | International Business Machines Corporation | Controlling data packet flows by manipulating data packets according to an actual manipulation rate |
GB0407144D0 (en) | 2004-03-30 | 2004-05-05 | British Telecomm | Networks |
-
2006
- 2006-01-31 DE DE602006011125T patent/DE602006011125D1/de active Active
- 2006-01-31 CN CN2006800035358A patent/CN101112056B/zh active Active
- 2006-01-31 AT AT06704070T patent/ATE452492T1/de not_active IP Right Cessation
- 2006-01-31 US US11/795,948 patent/US8498210B2/en active Active
- 2006-01-31 EP EP06704070A patent/EP1844583B1/en active Active
- 2006-01-31 WO PCT/GB2006/000330 patent/WO2006079845A1/en active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1545286A (zh) * | 2003-11-21 | 2004-11-10 | 清华大学 | 基于ecn且带预测验证的拥塞控制方法 |
Non-Patent Citations (2)
Title |
---|
Ivan Kai-Kin Leung, Jogesh.K.Muppala.Effect of Different Marking Strategies on Explicit CongestionNotification(ECN) Performance.2001 IEEE International Conference on Communications, New York, NY:IEEE, US,vol.1.1120,11812-1816. * |
N.Spring, D.Wetherall, D.Ely.Robust Explicit Congestion Notification (ECN) Signaling withNonces.IETF Standard, Internet Engineering Task Force.2003, * |
Also Published As
Publication number | Publication date |
---|---|
DE602006011125D1 (de) | 2010-01-28 |
US20080304413A1 (en) | 2008-12-11 |
ATE452492T1 (de) | 2010-01-15 |
EP1844583B1 (en) | 2009-12-16 |
CN101112056A (zh) | 2008-01-23 |
WO2006079845A1 (en) | 2006-08-03 |
EP1844583A1 (en) | 2007-10-17 |
US8498210B2 (en) | 2013-07-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101112056B (zh) | 对信息进行编码的方法 | |
Krolikowski et al. | Joint routing and scheduling for large-scale deterministic IP networks | |
US6643258B1 (en) | Communication resource management method and node device using priority control and admission control | |
CN101116292B (zh) | 管制网络 | |
EP1759495B1 (en) | Processing of data in networks | |
JP4474192B2 (ja) | ネットワークにおけるサービス品質の暗黙的弁別のための方法及び装置 | |
US20090059937A1 (en) | Network system for guarantee QoS | |
US7092359B2 (en) | Method for distributing the data-traffic load on a communication network and a communication network for implementing this method | |
US20090274165A1 (en) | Aggregated Resource Reservation for Data Flows | |
Robinson et al. | Sending the most recent observation is not optimal in networked control: Linear temporal coding and towards the design of a control specific transport protocol | |
Giuliari et al. | Colibri: a cooperative lightweight inter-domain bandwidth-reservation infrastructure | |
Luo et al. | Learning-based off-chain transaction scheduling in prioritized payment channel networks | |
K. Jayabarathan et al. | QoS enhancement in MANETs using priority aware mechanism in DSR protocol | |
Bless | A lower-effort per-hop behavior (LE PHB) for differentiated services | |
CN101129028B (zh) | 在具有接入控制的通信网络中估计带宽需求的方法和设备 | |
Patel | Comparative analysis of cumulative distribution function for TCP congestion window size and triple‐duplicate period | |
US8126004B2 (en) | Method for optimising the sharing of a plurality of network resources between a plurality of application flows | |
Zheng et al. | An overview of research on QoS routing | |
Rasmusson | Network capacity sharing with QoS as a financial derivative pricing problem: algorithms and network design | |
Stankiewicz et al. | Performance modeling of DiffServ meter/markers | |
He et al. | Completion time-aware flow scheduling in heterogenous networks | |
Bless | RFC 8622: A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services | |
Fung et al. | Quality of interaction among path computation elements for trust-aware inter-provider cooperation | |
Rasmusson | Network capacity sharing with QoS as a financial derivative pricing problem: algorithms and network | |
Park et al. | Feedback-based adaptive packet marking for proportional bandwidth allocation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |