CN101682627B - 用于网络装置的缓冲控制的方法 - Google Patents
用于网络装置的缓冲控制的方法 Download PDFInfo
- Publication number
- CN101682627B CN101682627B CN200880017500.9A CN200880017500A CN101682627B CN 101682627 B CN101682627 B CN 101682627B CN 200880017500 A CN200880017500 A CN 200880017500A CN 101682627 B CN101682627 B CN 101682627B
- Authority
- CN
- China
- Prior art keywords
- data
- packet
- minimum
- queue
- standard
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/23—Bit dropping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9084—Reactions to storage capacity overflow
- H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明的实施例提供一种队列缓冲管理的方法。对于本发明的一个实施例,在数据源装置处生成互联网协议数据。所生成的数据被传输至一个或多个网络装置并在一个或多个网络装置处被接收。基于指定的标准选择性地删除所生成的部分数据,以便改善所生成的数据的数据流。从自上一丢弃之后的时间、自上一被丢弃的数据包之后的数据包数量、数据包协议、数据包尺寸及其组合组成的组中选择指定的标准。对于本发明的一个实施例,所生成的数据经由流可控接口传输。
Description
技术领域
本发明的实施例涉及通信网络,更具体地,本发明涉及用于控制数据通信***的队列缓冲的***和方法。
背景技术
队列缓冲管理的传统方法包括配备流控制接口(flowcontrollable interface,FCI)。当网络装置连接到通过FCI提供数据源的主机时,当网络装置内的队列超出指定等级时,这些装置间的数据流通常被堵塞。配备FCI以防止在网络装置的队列一直溢出的情况下的数据流失(data loss)。当网络装置与主机之间的数据流被堵塞时,需要主机中的网络层来对数据进行排队,因为网络层之上的流控制是由传输层控制的。取决于传输层(TCP,UDP等)和传输参数(诸如rwin),在主机中经常出现过量的排队。
这样的***存在与过量的排队相关联的缺点。一个缺点是过量的排队会导致数据穿过从数据源到数据目的地(例如,网络装置)然后返回数据源的链路所需要的时间增加。该时间就是公知的信道的往返时延(round trip time(RTT))。RTT的增量等于排队数据量乘以网络装置的最大输出速率。
图1示出了根据现有技术配备有FCI的***及其缺点。对于TCP数据,RTT的增加和吞吐量的减少的根本原因是上行链路的接收窗口尺寸被远端服务器设置的太大。RTT的增加是由TCP协议之下的上行链路的数据路径中的过量的排队导致的,其中多个TCP会话被复用到一个流中(对于UDP数据,过量的排队在UDP流数据速率超出网络装置的输出速率的任何时间发生)。
TCP流的吞吐量降低是由典型的TCP FCI的下一数据通信过程引起的。由于应用程序发送数据至网络装置比数据能被发出的速率快,因此数据必须随着DL确认一同进行排队,如图1所示。排队的数据使得RTT增加,而RTT的增加导致了到远端数据源(未示出)的DL TCP确认的延迟。及时的TCP确认的缺少使得远端数据源降低了数据传输速率。
发明内容
本发明的实施例提供了一种用于队列缓冲管理的方法。对于本发明的一个实施例,互联网协议数据在数据源装置处生成,所生成的数据被传输至一个或多个网络装置并在一个或多个网络装置处被接收。基于指定的标准选择性地丢弃所生成的部分数据以改善所生成的数据的数据流。指定的标准选自由自上一丢弃之后的时间、自上一被丢弃的数据包(packet)之后的数据包数量、数据包协议、数据包尺寸及其组合组成的组中。对于本发明的一个实施例,所生成的数据经由流控制接口传输。
以下将对本发明的其它优点和实施例进行详细描述。
附图说明
通过参考以下描述和用于说明本发明实施例的附图,可以更好地理解本发明。在附图中:
图1示出了根据现有技术配备有FCI的***及其缺点;
图2示出了根据本发明的一个实施例的数据通信***;
图3示出了根据本发明的一个实施例的实现数据通信***的队列缓冲管理的过程;
图4示出了根据本发明的一个实施例的用于队列缓冲管理的方法的流程图;
图5示出了根据本发明的一个实施例的可以用于传送数据的数字处理***的功能框图;
图1A示出了固定拥塞阈值(Congestion Threshold)仿真;
图2A示出了固定拥塞阈值仿真-变化的输出DR;
图3A示出了不存在数据包间最小时间的固定拥塞阈值仿真;
图4A示出了固定最小时间间隔的仿真;
图5A示出了具有变化的输出速率的固定最小时间间隔的仿真;
图6A示出了固定最小数据包间隔仿真;
图7A示出了动态的拥塞控制仿真;
图8A示出了动态的最小时间间隔仿真;
图9A示出了具有UDP速率<物理输出速率的拥塞仿真;
图10A示出了具有UDP>物理输出速率的仿真;
图11A示出了具有动态的2级最小时间间隔机制的仿真;
图12A示出了使用具有变化的输出速率的DTSM的仿真;以及
图13A示出了使用具有变化的输出速率而没有UDP流量的DTSM的仿真。
具体实施方式
一种用于队列缓冲管理的方法和***,其中,基于指定的标准来选择性地删除接收到的数据,以便改善数据流。对于本发明的各个实施例,其中,***配备有FCI,指定的标准可以包括以下的各种组合中的一个或多个:队列深度、滤波的队列深度、上一丢弃数据之后的时间、上一丢弃数据之后的接收到的数据量、以及数据包尺寸和数据包协议(对于实现基于数据包的数据通信的***)。对于在非流可控制环境内实施的本发明的实施例,指定的标准可以包括以下的各种组合中的一个和多个:自上一丢弃的数据之后的时间、自上一丢弃的数据之后接收到的数据量、以及(对于实现基于数据包的数据通信的***)数据包尺寸和数据包协议。
本领域的普通技术人员将了解,本发明的各个实施例的以下详细描述只是说明性的,而并非旨在进行任何方式的限定。受益于本发明披露内容的技术人员能够容易地联想到本发明的其他的实施例。本领域普通技术人员应理解,这些具体的细节可能并不是实现本发明的实施例所必须的。在其他的情况下,以框图的形式示出已知的元件和装置,以避免使本发明难以理解。在以下实施例的描述中,基本上相同的部分由相同的参考标号表示。
为了清楚起见,并未示出和描述本文所描述的实施方式的所有特征。当然,应当理解的是,在开发任何这样的实际实施方式时,可以制作许多特定实施方式的装置以便达到开发者的特定目的,其中这些特定目的将从一个实施到另一个实施以及从一个开发者到另一个开发者发生变化。此外,应当理解的是,这样的开发努力可能是复杂且耗时的,但是对于获益于本公开的本领域的普通技术人员来说,只不过是日常的工程任务。
根据本发明的实施例,可以使用各种类型的操作***、计算平台、计算机程序、和/或通用机器来实现各元件、处理步骤、和/或数据结构。另外,本领域的普通技术人员应理解,在不背离本文中所公开的本发明构思的范围和精神的情况下,还可以使用不太通用类型的装置。
尽管已示出和描述了本发明的特定实施例,但是对于获益于本公开的本领域的技术人员来说,显而易见的是,在不背离本文中所公开的本发明构思的情况下,可以有比以上所述多得多的修改。此外,所列出的发明点少于单个所公开的实施例的所有特征。因此,具体实施方式之后的权利要求从而可以清楚地与该具体实施方式相结合,以及每个权利要求基于其本身可以作为本发明的一个单独的实施例。
图2示出了根据本发明的一个实施例的数据通信***。如图2所示,***200包括生成数据(例如,互联网协议数据)的数据源装置205。所生成的数据被传输至接收数据的一个或多个网络装置(例如所示的网络装置210)。网络装置通过本领域已知的有线或无线通信设备通信地连接至数据源装置。对于本发明的一个实施例,网络装置210通过诸如(例如)USB、PCMCIA、Expresscard、PCIExpress Mini或系列的FCI通信地连接至数据源装置205。
网络装置210包括队列管理功能215,其基于指定的标准(例如所示的标准RTT、输出数据率以及队列深度)来确定是否删除接收到的数据的一部分(例如,丢弃数据包)。
队列管理功能215连接至多路复用器220,通过多路复用器可以实现丢弃或删除数据的确定,如图2所示。
图3示出了根据本发明的一个实施例的实现数据通信***的队列缓冲管理的过程。本发明的可选的实施例提供了一种解决过量排队问题而仍能保持最大网络装置输出速率的队列管理方法。
如图3所示,过程300在操作305处开始,在操作305处,数据被从数据源装置接收至执行队列缓冲管理方案的网络装置。
在操作310处,基于指定的标准对接收到的数据进行估计。指定的标准可以包括数据通信***的静态和动态参数。例如,动态参数可以包括拥塞阈值、最小时间间隔、最小丢弃数据包尺寸、以及数据协议,其可以是(例如)输出数据速率、RTT和队列深度的函数。
对于本发明的一个实施例,可以在数据通信之前或数据通信期间动态确定一个或多个指定的标准。对于本发明的各个可选的实施例,一个或多个指定的标准具有相应的值(例如,字节、秒等),该值可以在数据通信之前或数据通信期间动态确定。
在操作315处,基于估计来选择性地删除部分数据以便改善数据通信***的数据流。
图4示出了根据本发明的一个实施例的用于队列缓存管理的方法的流程图。
如图4所示,对于本发明的一个实施例,队列管理过程使用输入信号:所估计的信道RTT、所估计的输出数据速率、以及当前的队列深度。该过程确定队列中的部分数据(例如,数据包)是否应该被发送至协议的下一层。
对于本发明的一个实施例,队列管理方法是由TCP拥塞控制机制驱动的,其可以降低拥塞窗口从而减少在拥塞标记处的非确认数据或正在处理的数据的量。正在处理的数据越少,数据源装置发送数据就越慢。可以利用两种方法来向发送TCP栈指示拥塞:丢弃的数据包或TCP包头中的明确的拥塞通知标记的设置。以其非常基本的方式,队列管理就可以监控队列深度。当队列深度超出某些阈值(例如,本文件中的拥塞阈值)时,其通过丢弃数据包或触发明确的拥塞通知来触发TCP拥塞控制机制。队列深度只是队列管理***在丢弃数据包之前需要考虑的多个因素中的一个因素。
对于本发明的一个实施例,队列管理***的输入是一组实时控制信号以及可调的常数。以下是对于变化的***数据速率和RTT的用于控制队列管理***的基本可调常数的列表。
如图4所示,根据本发明一个实施例的方法可以使用一个或多个包括以下的可调参数。
拥塞阈值:当平均队列长度和当前队列长度超出该阈值时丢弃数据包。
最小时间间隔:自上一个丢弃的数据包之后,该时间量过去后才考虑丢弃数据包。
最小数据包间隔:自上一个丢弃的数据包之后,该多个数据包被发送后才考虑丢弃数据包。
最小丢弃数据包尺寸:该常数是必须被考虑要丢弃的数据包的最小尺寸。
考虑丢弃的传输协议:这包括考虑确定删除(丢弃)数据的传输协议的列表。可以考虑诸如TCP或UDP的一些协议。可以不考虑丢弃诸如ICMP、RTP等的其他协议。
附录A所包括的是用于实施这些标准和实施用于确定是否删除信息以实现队列缓冲管理和改善数据流的其他考虑的方法的示例。
再参考图2,本领域的技术人员可以理解数据源装置205和网络装置210可以是各种数字处理***(DPS)中的任何一种。图5示出了根据本发明的一个实施例的可以用于传输数据的数字处理***的功能框图。如图5所示,处理***500的部件是示例性的,其中可以省略或添加一个或多个部件。例如,一个或多个存储装置可以用于处理***500。
参考图5,处理***500包括中央处理单元502和经由总线501连接至主存储器504、静态存储器506和大容量存储装置507的信号处理器503。根据本发明的实施例,主存储器504可以存储可选择的通信应用程序,而大容量存储装置507可以存储上述所讨论的各种数字内容。处理***500还可以经由总线501连接至输入/输出(I/O)装置525和音频/语音装置526。总线501是用于传输信息和信号的标准***总线。CPU 502和信号处理器503是处理***500的处理单元。可以使用CPU 502或信号处理器503或二者可以用来处理处理***500的信息和/或信号。CPU 502包括控制单元531、算术逻辑单元(ALU)532、以及若干个寄存器533,其用来处理信息和信号。信号处理器503还可以包括与CPU 502类似的部件。
主存储器504可以是例如随机存取存储器(RAM)或一些其他的动态存储装置,用于存储CPU 502或信号处理器503使用的信息或指令(程序代码)。主存储器504可以存储CPU 502或信号处理器503执行指令期间的临时变量或其他中间信息。静态存储器506可以是例如只读存储器(ROM)和/或其他静态存储装置,用于存储也可以被CPU 502或信号处理器503使用的信息或指令。大容量存储装置507可以是例如硬盘驱动器或光盘驱动器,用于存储处理***500的信息或指令。
通用内容
本发明的实施例提供了用于实现数据通信***中的队列管理的方法和***。对于本发明的一个实施例,在数据源装置处生成互联网协议数据。所生成的数据被传输至一个或多个网络装置并在一个或多个网络装置处被接收。基于指定的标准来选择性地删除所生成的部分数据以实现所生成的数据的改善的数据流。对于本发明的一个实施例,所生成的数据经由流可控接口传输。
本发明的可选实施例提供队列管理方法,其可以解决过量的排队问题而仍能保持最大网络装置输出速率。
本发明的实施例包括诸如传输、缓冲和处理数据的各种操作。对于各种实施例,可以添加或删除一个或多个所描述的操作。例如,存在若干可选的方法:可以使用网络装置来获取估计的RTT和估计的输出数据速率。通过检测已经发送的数据所消耗的时间来测量RTT。如果数据在进入网络装置时被加密,则以这种方式所计算的RTT是不合理的。可选地,如果网络装置可以生成低速率查验(ping)至已知的静态IP地址或可以在队列中找到的IP地址,则可以估计RTT。此外,可以基于物理层的信道条件来进行固定的最坏情况下的RTT或一般情况下的RTT估计。可以通过测量数据退出队列的速率来计算输出数据速率和/或可以由物理层信道访问授权来确定输出数据速率。
本发明的操作可以由硬件部件执行或被包含在机器可执行的指令中,其可以用来使得通用或专用处理器或用指令编程的逻辑电路执行这些操作。可选地,可以由硬件和软件的组合来执行操作。本发明的实施例可以提供为计算机程序产品,该计算机程序产品可以包括具有存储在其上的指令的机器可读介质,其可以用来对计算机(或其他的电子装置)进行编程以执行根据本发明的进程。机器可读媒介可以包括但不限于光盘、CD-ROM和磁光盘、ROM、RAM、EPROM、EEPROM、磁或光卡、闪存、或适于存储电子指令的其他类型的媒体/机器可读媒介。此外,本发明还可以被下载来作为计算机程序产品,其中,该程序可以通过包含在载波中或其他传播媒介中的数据信号的方式经由通信单元(例如,调制解调器或网络连接)从远程计算机转移至需要的计算机上。
进一步地,虽然在具体内容中描述各种实施例,但是本发明的实施例可以应用到包含采用多个数据标准的各种单信道或多信道数据传输***。
尽管根据若干实施例已经描述了本发明,但是本领域的技术人员可以了解,本发明不限于所描述的这些实施例,而在所附权利要求的精神和范围内可以进行修改和改变。从而,认为描述是解释性的而不是限定性的。
附录A
可调的参数
对于本发明的一个实施例,队列管理***的输入是一组实时控制信号和可调常数。以下是对于变化的***数据输出速率和RTT的用于控制队列管理***的基本可调常数的列表:
·拥塞阈值:
当平均队列长度和当前的队列长度超出该阈值时丢弃数据包。
·最小时间间隔:
自上一个丢弃的数据包之后,该时间量过去后才考虑丢弃数据包。
·最小数据包间隔:
自上一个丢弃的数据包之后,该多个数据包被发送后才考虑丢弃数据包。
·最小丢弃数据包尺寸:
该常数是必须考虑要丢弃的数据包的最小尺寸。
·考虑丢弃的传输协议:
这包括考虑丢弃的传输协议的列表,诸如TCP或UDP。可以不考虑丢弃诸如ICMP、RTP等的其他协议。
峰负载考虑(consideration)
可选地,队列管理***应该包括防止由峰输入爆发(peakincoming burst)导致的数据包丢弃。由于IP数据流量的爆发特性,发送至队列的流量的大的爆发是很平常的。本发明可以避免由任何流量爆发导致的丢弃数据包。推荐实施一种机制,其中将拥塞阈值与队列长度的即时测量和队列长度的滤波(或平均或平滑)形式进行比较。
可以用于避免峰负载时丢弃数据包的另一个机制要求在丢弃数据包之前的特定时间段内队列长度超出拥塞阈值(CngTh)。该机制的缺点是在作用于过量的排队时一直存在延迟,这将降低性能。
控制数据包考虑
应避免确认数据包或其他的控制数据包的丢弃,因为他们不能触发TCP栈中的拥塞控制算法。对数据包进行解析以确定数据包类型,可以用来减少控制数据包的丢弃。如果数据包被加密,则就不可能对他们进行解析。在这种情况下,可以使用数据包的尺寸来确定该数据包是否是确认数据包或其他更小的控制型数据包(ICMP还趋于更小)。理想地,只有接近最大段尺寸(maximum segmentsize)的数据包才考虑丢弃。可以使用现有队列管理***中的常量最小丢弃数据包尺寸来设置需要考虑丢弃的数据包的最小尺寸。
本文件中所示的所有仿真结果设置最小丢弃数据包尺寸=1200字节。
头对尾(head versus tail)丢弃考虑
为了协助TCP即时地响应触发,应该从队列的前面或头部(正好要发送出网络装置的数据包)来丢弃将要被丢弃的数据包。从队列的前面丢弃数据包还可以帮助确保在其后有足够的数据来触发可选择的ACK(SACK)以启动拥塞机制(TcpMaxDupAcks=2)否则TCP栈就要在数据包上超时,这将导致输出性能的降低。因此,最好是队列和队列管理尽可能地接近MAC或物理层。虽然从队列的头部丢弃数据包是最优化的,但是可以在队列中的任何地方进行丢弃。
本文件中所示的所有仿真结果均使用头部丢弃机制。
静态队列管理方法
该部分讨论使用关于拥塞阈值、最小时间间隔和最小数据包间隔控制信号的静态信号的队列管理***。因而,没有使用图4A所示的CongThFunc函数、MinTimeIntFunc函数和MinPacketIntFunc函数。随后将讨论动态队列管理***。
拥塞阈值信号
拥塞阈值是用于确定何时丢弃数据包的多个控制信号中的一个控制信号。假设满足(pass)另一个数据包丢弃条件,上述流程图示出在当前的队列长度和滤波(或平滑)队列长度超出拥塞阈值时丢弃数据包。
在某种意义上,拥塞阈值设置TCP拥塞窗口(cwin)。由于最大TCP拥塞窗口是由正在接收数据(见RFC 2581)的TCP栈设置的接收窗口(rwin)设置的,所以其可以增长。为了最大化TCP吞吐量和最小化排队,应该将rwin设置为延迟带宽积(RTT*输出数据速率)。类似地,在队列管理***中,拥塞阈值最优地被设置为约略地等于延迟带宽积(DBP)。具有该阈值设置后,TCP拥塞窗口可以从2乘以DBP变化至1乘以DBP。设置为DBP的拥塞阈值是最优的点,在该点可以获得最大的输出数据速率并且出现最小的排队。
图1A示出了具有网络装置输出速率设置为16kB/s和0.4s的信道RTT的队列管理***的仿真结果。拥塞阈值设置在DBP(16*0.4=6.4kB)处。队列管理***的输入是单个的TCP数据流,其具有无穷的数据源并从而一直试图以TCP栈的限制内的最大可允许速率发送数据。
仿真参数:
拥塞控制算法参数
6400 MAX_CngTh 最大拥塞阈值。
6400 MIN_CngTh 最小拥塞阈值
1200 DropSizeTh-丢弃尺寸阈值(以字节方式表示)要丢弃的数据包的最小尺寸。范围300-1500字节。
0 MinPacketInterval-丢弃间的最小数据包数量
1.3 MinDropInterval(秒)丢弃的数据包间的最小时间量
物理层
16 输出数据速率(KB/S)
从图1A,我们可以看出TCP慢启动机制出现之后,采取TCP拥塞机制。所示的TCP拥塞窗口如先前所述的在变化。输出数据速率等于最大物理输出数据速率。队列尺寸从~6400字节变化至0,这是不发生数据欠载运行的可能的最小队列尺寸。
拥塞阈值设置考虑
如果设置的拥塞阈值太大(大于DBP),则会导致过量的排队。如果设置的拥塞阈值太小(小于DBP)则会降低队列的输出数据速率。图2A中的仿真结果示出了这些效应,图2与图1A中的队列管理***相同,但是这段时间的物理输出数据速率是随时间变化的以产生不同的DBP。
仿真参数:
拥塞控制算法参数
6400 CngTh 最大拥塞阈值。
1200 DropSizeTh-丢弃尺寸阈值(以字节方式表示)要丢弃的数据包的最小尺寸。范围300-1500字节。
0 MinPacketInterval-丢弃间的最小数据包数量
1.3 MinDropInterval(秒)丢弃的数据包间的最小时间量
输出数据速率
16 初始速率(字节/秒)
25 改变输出速率的时间(秒)
8 改变的速率(字节/秒)
45 改变输出速率的时间(秒)
32 改变的速率(字节/秒)
在输出数据速率等于8kB/s的时间段期间,虽然输出数据速率等于8kB/s,但是在那时存在的排队比必要时更多。在输出数据速率等于32kB/s的时间段期间,当队列为空时输出数据速率下降并从而小于32kB/s。
最小时间间隔(Min Time Interval)
最小时间间隔是用于确定何时丢弃数据包的多个控制信号中的另一个控制信号。假设满足(pass)了所有其他的丢弃数据包的条件,则上述流程图所示只当自上一个丢弃之后的时间大于最小时间间隔时才丢弃数据包。最小时间间隔可以具有两个目的。第一个目的是在另一个数据包被丢弃之前留给TCP栈一定的时间以对所丢弃的数据包作出反应。第二个目的类似于拥塞阈值的目的,其用来设置合适的时间来丢弃数据包。
当最小时间间隔只用来阻止多个数据包被丢弃时,应该将其设置为TCP对所丢弃的数据包作出反应所消耗的时间。计算出的该时间稍微地大于2乘以RTT再加上遍历队列进行重试所消耗的时间长度(该时间的详细计算在以下部分进行推导)。使用来自图1A所示的我们的仿真结果的参数,所计算的最小时间间隔的时间为:
2*0.4(RTT)+6400(丢弃出现时的Q尺寸)/16000(输出速率)+0.1=1.3sec
该信号的使用是很关键的,否则队列管理***将会丢弃多于一个数据包。图3A示出了具有固定的拥塞阈值的相同的队列管理***,但是这段时间的最小时间间隔设置为0。
仿真参数:
拥塞控制算法参数
6400 CngTh 最大拥塞阈值。
1200 DropSizeTh-要丢弃的数据包的最小尺寸。范围300-1500字节。
0 MinPacketInterval-丢弃间的最小数据包数量
0 MinDropInterval(秒)丢弃的数据包间的最小时间量
物理层
16 输出数据速率(KB/S)
该仿真的输出示出多个数据包被丢弃因而TCP栈通过迅速地降低拥塞窗口而作出反应。该紧闭(intern)导致了数据欠载运行并降低了输出数据速率。
第二个目的是主要依靠最小时间间隔来控制队列等级。在这种情况下,可以将拥塞阈值设置为几乎是任何一个任意的数量。最优的最小时间间隔的计算比最优的拥塞阈值的计算稍微更复杂些。
将要使用以下的变量来推导用于确定最优的最小时间间隔的公式:
MaxQ=队列应该增大至DBP的最优的最大量=RTT*DR
DR=输出数据DR
Cwnd=拥塞窗口
RTT=往返时延
IPSegSize=IP数据包的尺寸
TCPSegSize=TCP数据包的尺寸
AcksPerSec=每秒收到的确认
TimeToReduceCwnd=TCP栈从所丢弃的数据包后至1/2Cwnd的值所消耗的时间
TimeToGrowQueue=队列从MaxQ增长所消耗的时间
TimeToGrowCWnd=TCP栈将Cwnd从MaxQ增长至2*MaxQ所消耗的时间
优选地,最小时间间隔等于队列填满至MaxQ所消耗的时间加上TCP栈对所丢弃的数据包作出反应所消耗的时间。
最小时间间隔(Min Time Interval)=TimeToGrowQueue+TimeReduceCwnd
增长队列至MaxQ所消耗的时间等于TCP栈将拥塞窗口从MaxQ增长至2*MaxQ所消耗的时间,然后:
最小时间间隔(Min Time Interval)=TimeToGrowCwnd+TimeReduceCwnd
TimeReduceCwnd的计算
TCP栈从所丢弃的数据包至1/2Cwnd的值所消耗的时间等于ack从重试到被接收所消耗的时间。该时间可以分成为:
SACK被接收到所消耗的时间=RTT
转发的数据包被发送所消耗的时间=排队时间=MaxQ/DR
接收到转发的数据包的确认所消耗的时间=RTT
因此,然后:
TimeReduceCwnd=RTT+MaxQ/DR+RTT=2*RTT+MaxQ/DR
将MaxQ=DR*RTT代入:
TimeReduceCwnd=2*RTT+DR*RTT/DR=3*RTT
TimeToGrowCWnd的计算:
Cwnd从MaxQ尺寸增长至2*MaxQ尺寸所消耗的时间量为:
TimeToGrowCWnd=MaxQ/CwndGrowthRate
每当ack被接收时,拥塞窗口增长的速率等于TCPSegSize^2/Cwnd字节。
CwndGrowthRate=(TCP SegSize^2/Cwnd)*AcksPerSec
AcksPerSec=DR/IPSegSize
上述等式由于Cwnd不是常数而变得复杂。为了简化该等式,我们将使用等于1.7*MaxQ的平均Cwnd。将其替代Cwnd代入,有:
CwndGrowthRate=TCPSegSize^2/(1.7*MaxQ)*DR/IPSegSize
化简,有:
最小时间间隔的计算:
将CwndGrowthRate和TimeReduceCwnd代入有:
将MaxQ=DR*RTT代入并化简,有:
使用以下值:
DR=16000字节/秒
RTT=0.4秒
IPSegSize=1500
TCPSegSize=1450
然后最小时间间隔=1.7*16000*0.4y2*1500/(1450y2)+3*0.4=4.3秒
为了示出队列管理***怎样工作,使用固定的信号最小时间间隔作为主要的丢弃判断标准,用图4A中的仿真输出结果来运行仿真,以及数据包间的最小时间设置为4.3秒。
仿真参数
拥塞控制算法参数
3000 CngTh最大拥塞阈值
4.3 MinDropInterval(秒)丢弃的数据包间的最小时间量
物理层
16 输出数据速率(KB/S)
仿真示出:即使将拥塞阈值设置为仅仅3000字节,但是队列管理是最优化的(尽管还是使用所有可利用的输出数据速率,但具有最少的排队),因为通过将最小时间间隔设置为4.3秒限制了丢弃。
类似地使用静态的拥塞阈值,当最小时间间隔没有设置为最优的值时,使用固定的最小时间间隔将会产生过量的排队或将不能利用所有可利用的输出速率。为了示出该效果,执行速率在16、8和32kB/sec变化的仿真。图5A示出了该仿真的结果。
仿真参数:
拥塞控制算法参数
3000 CngTh 最大拥塞阈值
0 MinPacketInterval-丢弃间的最小数据包数量
4.3 MinDropInterval(秒)丢弃的数据包间最小时间量
输出数据速率
16 初始速率(KB/sec)
25 改变输出速率的时间(秒)
8 改变的速率(KB/sec)
45 改变输出速率的时间(秒)
32 改变的速率(KB/sec)
这些结果类似于使用静态拥塞阈值的队列管理***的结果。在物理输出速率等于8kB/s期间内,队列平均输出数据速率等于8kB/s但是存在的排队比必要时更多。在物理输出速率等于32kB/s期间内,当队列为空时队列平均输出速率下降并从而小于32kB/s。
最小数据包间隔
最小数据包间隔是用来确定何时丢弃数据包的多个控制信号中的另一个控制信号。假设满足所有其他的丢弃数据包条件,上述流程图示出当自上一个丢弃之后的数据包的数量多于最小数据包间隔时才对数据包进行丢弃。该信号的使用同最小时间间隔的使用相同。可以用来在丢弃另一个数据包之前等待TCP栈对丢弃的数据包作出反应,或可以用作***的初始控制。
典型地,队列管理***可以不需要支持这些机制中的两个机制,但是需要基于便于实现来选择好于另一个的一个。最优的最小数据包间隔的计算如下:
最小数据包间隔(Min Packet Interval)=(DR/IPPacketSize)*Min Time Interval
使用的仿真参数是来自图1A所示的仿真结果,最小数据包间隔的结果为:
最小数据包间隔(Min Packet Interval)=(16000/1500)*4.3=46数据包
使用等于46的固定值,用图6A中所示的结果执行仿真。
仿真参数:
拥塞控制算法参数
3000 CngTh 最大拥塞阈值
46 MinPacketInterval-丢弃间的最小数据包数量
0 MinDropInterval(秒)丢弃的数据包间的最小时间量
物理层
16输出数据速率(KB/sec)
上述仿真结果示出:即使将拥塞阈值设置为仅仅3000字节,但是队列管理是最优化的(尽管还是使用所有可利用的输出数据速率,但具有最少的排队),因为通过将最小数据包间隔设置为46限制了丢弃。
多个TCP流的考虑
虽然本文件中示出的所有仿真结果是用于仅一个TCP流的情况,但是可以调整所有的队列管理算法以适当地支持具有多于一个平行TCP流的输入数据流。
当拥塞阈值信号用来作为主要的丢弃标准时,在用多个TCP流作为输入时算法将会比较好的运行。这是真实的,因为***将可能会从具有最高的cwnd的数据流中丢弃数据包,因为这将会发送最多的数据并且队列中具有最多的数据。虽然,如果算法不幸地删除了来自低速率TCP流中的数据包则可能存在一些短期的队列深度峰值,但是在长期中会将其平滑掉。
当最小时间间隔或最小数据包间隔被用作主要的丢弃标准时,则需要调整算法。为了保持最优化尺寸(DR*RTT)的队列,丢弃速率需要与有效地发送TCP流成比例。因而,需要根据有效地发送TCP流的数目来调整最小时间间隔或最小数据包间隔。通过查看队列中的数据包的IP和TCP包头可以很容易地计算有效的TCP流的数目。用所调整的最小时间间隔或最小数据包间隔,可以执行算法,类似于基于拥塞阈值信号的算法,其中如果算法不幸地从低速率TCP流中删除了数据包则可能出现一些短期的队列深度峰值。
取决于协议的丢弃
期望队列管理***仅考虑用于丢弃的更高层协议的某些类型。诸如SIP、RTSP、RSPP或RTCP的更高层控制协议可能是候选的,其是被优选的以不被丢弃的协议,因为它们不会导致流量显著的减慢以及可以引起终端用户体验显著的下降。所有的UDP流量还可以在这种“不丢弃列表”中,因为UDP流量将反应为使用拥塞控制算法运行的TCP是不可能的。如果UDP速率大于输出数据速率,则会出现把UDP数据包排除之外的问题。在这种情况下,需要丢弃UDP数据包。为了适当地处理这种情况,可以将第二组阈值添加至算法(UDP拥塞阈值),其中上述该阈值UDP数据包将会具有更强的用于丢弃的目标性而不是丢弃TCP数据包。
(VPN)加密前的处理
该文件中存在的一些概念需要队列管理器来解析或遍历数据包以确定密钥的一些关键属性,诸如尺寸、协议、端口数等。为了获得最好的性能,需要将队列管理器置于尽可能地离物理层近(见“头对尾丢弃”部分)。将队列管理器置于该位置处的问题是如果使用VPN或其他的密码术加密,则当其到达队列管理器时所有的信息被加密并从而不能提取这些密钥属性。
该问题的解决办法可以是添加置于VPN之前而网络层之后的协调实体。在微软Vista OS中,这种类型的驱动器被称作为过滤驱动器(filter driver)。然后,过滤驱动器可以对队列管理器将考虑要丢弃的数据包做标记。标记数据包的方法可以通过频带外的信令或通过修改VPN或其他的密码术没有对其加密的数据包的多个字段中的一个字段来实现。该机制在本文件的范围之外。
动态队列管理***
迄今,本文件和现有的仿真结果只是考虑了静态方式下的控制信号的使用。使用运行时间函数以计算诸如拥塞阈值的关键队列管理控制信号,以帮助队列管理***适应物理层中的变化以及输入数据流的变化。物理层的变化可以包括数据速率和/或RTT变化。输入流量流的变化可以包括输入流量速率和/或协议混合(TCP vs.UDP或其他的)。所列出的三个函数(CongThFunc、MinTimeIntFunc、和MinpacketIntFunc)可以用来动态地计算控制信号拥塞阈值、最小时间间隔和最小数据包间隔。这些函数的使用是可选的。为了简单或如果期望***有小的变化,可以选择控制信号是静态的。如果期望队列管理***修改(adapt),则可以使用上述列出的动态控制信号函数中的一个或多个或全部。队列管理方法可以使用这三个函数,但是可能只使用这些函数中的一些而其他的信号被固定。以下部分描述了执行这些函数的一些一般性原则。
CongThFunc描述
如先前所提及的,为了最大化TCP吞吐量和最小化排队,拥塞阈值总是被设置为DBP。在许多的***中,输出数据速率和较小扩展的RTT可以显著地变化,因此基于RTT的估计值和输出数据速率来使用拥塞阈值的动态计算是有利的。
存在若干个用来估计输出数据速率的机制,诸如测量队列之外的数据流或使用诸如信道授权或信号条件的一些物理层信息。输出数据速率的估计还可以简单地基于物理连接技术(GPRS、EDGE、或WCDMA、1x、Ev/DO rev0或revA)。不论使用那一种方法,可以平滑输出数据速率的估计,使得物理层中的快速变化不引起拥塞阈值的显著变化。
还可以存在若干个用来估计信道的RTT的机制。如果TCP数据被发送,则很容易地计算出RTT作为远端接收机确认发送的数据所消耗的时间。如果使用VPN,则该测量需要在加密层之上完成。另一个用于估计RTT的方法是发送诸如查验(ping)的小数据包至已知的服务器。该方法的缺点是其可以产生一些***开销并且不能在数据包被发送的位置处测量RTT。
以下的仿真结果是对于拥塞阈值被动态地设置为DBP=RTT*输出数据速率的队列管理***。所有其他的控制信号是静态的。通过数据退出队列的速率来估计输出数据速率。然后,使用单极IIR移动平均滤波器来对输出数据速率滤波。对于该仿真,没有估计RTT而是将其固定在某个值(EstRTT)。对于该仿真,实际的RTT是0.4秒而EstRTT被设置为0.4375秒。实际的物理数据速率从16kB/s至8kB/s至32kB/s变化。队列的输入数据是单一的TCP流。图7A示出了仿真的结果:
仿真参数:
拥塞控制算法参数
3000 Start_CngTh 初始拥塞阈值
2 MinDropInterval(秒)丢弃的数据包间的最小时间量
0.4375 EstRTT-用于计算CngTh=AveULDR*CongCtrlRTT所估计的RTT
输出数据速率
16 初始速率(KB/sec)
25 改变输出速率的时间(秒)
8 改变速率(KB/sec)
45 改变输出速率的时间(秒)
32 改变速率(KB/sec)
从上述结果可以看出,虽然实际物理数据速率从16kB/s至8kB/s至32kB/s变化,但是队列的输出数据速率总是趋于等于物理数据速率,并且在任何数据速率下不存在过量的排队。
最小时间间隔函数(MinTimeIntFunc)描述
如先前所提及的,如果控制信号最小时间间隔用作控制队列尺寸的主要信号,则应该将最小时间间隔设置为:
DR=输出数据速率
类似于动态的拥塞阈值,最小时间间隔还可以基于RTT的估计和物理输出数据速率来动态地计算。虽然上述计算看起来比较复杂,但是可以简化为IPSegSize和TCPSeqSize作为通常的常数,则:
最小时间间隔(Min Time Interval)=K*DR*RTT^2+3*RT
其中:
K~=1.7*IPSegSize/TCPSegSize^2
可以使用相同的方法来估计先前提及的RTT和输出数据速率。
以下的仿真结果是关于队列管理***的,其中最小时间间隔被动态地计算为:
最小时间间隔(Min Time Interval)=K*DR*RTT^2+3*RT
所有其他的控制信号是静态的。可以通过数据退出队列的速率来估计输出数据速率。然后,使用单极IIR移动平均滤波器来对输出数据速率进行滤波。对于该仿真,没有估计RTT而是将其固定在某个值(EstRTT)。在这种情况下,实际的RTT是0.4秒而EstRTT被设置为0.4375秒。实际的物理数据速率从16kB/s至8kB/s至32kB/s变化。队列的输入数据是单一的TCP流。图8A示出了仿真的结果。
仿真参数:
拥塞控制算法参数
3000 Start_CngTh 初始拥塞阈值
2 MinDropInterval(秒)-丢弃的数据包间的初始最小时间量
0.4375 EstRTT-用于计算MinDropInterval所估计的RTT
输出数据速率
16 初始速率(KB/sec)
25 改变输出速率的时间(秒)
8 改变的速率(KB/sec)
45 改变输出速率的时间(秒)
32 改变的速率(KB/sec)
从上述结果可以看出,虽然实际物理数据速率从16kB/s至8kB/s至32kB/s变化,但是队列的输出数据速率总是趋于等于物理数据速率,并且不存在过量的排队。
最小数据包间隔函数(MinPacketIntFunc)的描述
MinPacketIntFunc用来使最小数据包间隔控制信号动态。如先前所提及的,如果控制信号最小数据包间隔用作控制队列尺寸的主要信号,则应该将最小数据包间隔设置为:
最小数据包间隔=(DR/IPSegSize)*最小时间间隔
DR=输出数据速率
上述公式中存在仅有的变量,因此公式可以简化为:
最小数据包间隔=K1*DR^2*RTT^2+K2*RTT*DR
可以使用相同的方法来估计先前所提及的RTT和输出数据速率。
对流量而非TCP的考虑
到此为止,所有仿真的队列输入均是单一的TCP流。以下部分将着眼于队列管理***对包括诸如UDP(其不执行与TCP IP流量相同的拥塞控制规则)的IP流量的输入流如何反应。
以下仿真是使用与图7A所示的相同的队列管理***,其中,只有拥塞阈值是动态的而使用的所有其他的控制信号是静态的。队列的输入数据流是6kB/sec的TCP数据流和UDP数据流,并且物理输出速率是在8kB/s与32kB/s间变化的。图9A示出了结果:
仿真参数
UDP参数
6000 UDP_DR-UDP数据速率(字节/秒)
拥塞控制算法参数
3000 Start_CngTh 初始拥塞阈值
0 MinPacketInterval-丢弃间的数据包的最小数量
2 MinDropInterval(秒)-丢弃的数据包间的初始最小时间量
0.4375 EstRTT-用于计算MinDropInterval所估计的RTT
输出数据速率
16 初始速率(KB/sec)
60改变输出速率的时间(秒)
8改变速率(KB/sec)
90改变输出速率的时间(秒)
32改变速率(KB/sec)
上述结果示出:队列的输出数据速率是趋于等于物理层输出,这是很好的但是在一些实例中,诸如48秒标记(mark)和80秒标记处,当在一行中丢弃太多数据包时就会出现过量的排队。最小时间间隔可以防止队列管理过快地丢弃数据包。
如果UDP增大到物理输出数据速率之上,则过量的排队的问题变得不可管理。以下是除了UDP被设置为18kB/s而物理输出数据速率仅为16kB/s之外与上述***相同的***的仿真。从图10A的曲线可以看出,队列尺寸不可控制地增长,这是因为队列管理***不能足够快地丢弃数据包。
本文下一部分略述了算法的附加,其可以被实现以修正这个问题。
协议指定丢弃规则
该问题的一个解决方案是结合用于丢弃的协议指定规则。例如,UDP数据包相对于TCP数据包,最小时间间隔是不同的。对于UDP数据包,最小时间间隔能够并且应该接近零,因为不像TCP数据包,其不需要等待拥塞控制来进入队列。对于不同的协议,拥塞阈值、最小数据包间隔、以及丢弃尺寸也是不同的。该方法的主要缺点是其需要队列管理***能够解析数据包以确定正在发送的传输协议。除了处理缺点之外,如果使用VPN或其他的加密,则队列管理***不能解析数据包以确定协议类型。如先前所提及的,该加密问题的可能解决方法是在加密前使用诸如过滤驱动器的实体以确定所使用的协议然后相应地标记数据包。
动态的两级最小丢弃间隔机制
解决过量的排队的问题的另一个方法是将附加的逻辑添加至队列管理方法,其在本文件中被称作“动态的两个级的最小丢弃间隔”或DTSM。DTSM的基本原理是当队列过量地超出拥塞阈值时将最小丢弃间隔缩短。最小丢弃间隔应该缩短的量与当前队列深度超出拥塞阈值的多少相关。推荐的方法是定义新的控制参数,其被称为拥塞阈值超出比率(CngThExceedRatio)。CngThExceedRatio是队列深度可以超出拥塞阈值的百分比量,其中最小时间间隔将等于零。以下的等式添加了更详细的描述和解释。
假设:
基本最小丢弃间隔:
当队列深度小于拥塞阈值时的最小丢弃间隔。
CngThExceedRatio:
队列深度能够超出拥塞阈值的百分比量
其中最小时间间隔将等于零
当队列深度超出拥塞阈值时,最小丢弃间隔计算如下:
最小丢弃间隔=基本最小丢弃间隔*MinDropIntervalMultiplier
否则:
最小丢弃间隔=基本最小丢弃间隔
存在无数可能的方法来计算MinDropIntervalMultiplier。以下是计算的约束条件:
·MinDropIntervalMultiplier=1.0当队列深度等于拥塞阈值
·MinDropIntervalMultiplier=0.0当队列深度等于拥塞阈值*CngThExceedRatio
·MinDropIntervalMultiplier应该随着ExceedRatio的增加而增加
ExceedRatio是队列深度超出拥塞阈值的百分比,可以计算为:
可以使用下述的简化的线性插值公式来计算最MinDropIntervalMultiplier:
MinDropIntervalMultiplier=1-ExceedRatio/CngThExceedRatio
可选地,但是更复杂的,可以使用指数(exponential)关系来计算MinDropIntervalMultiplier,其由以下给出:
MinDropIntervalMultiplier=1-ExponentialB aseExceedRatio/CngThExceedR atio
由于当队列深度超出拥塞阈值*CngThExceedRatio时,指数公式返回负数,所以MinDropIntervalMultiplier必须限定在0-1的范围内。虽然指数函数是计算更密集的函数,但是其允许使用较小的CngThExceedRatio而不错误地丢弃数据包。
由于队列深度可以很快地变化,推荐的是,应将所计算的最小丢弃间隔平滑或滤波以移除可能出现的瞬时现象(transient)。该滤波将减少由于队列深度中自然出现的峰值而错误地缩短最小丢弃间隔的可能性。
使用动态的两个级的最小丢弃间隔机制(DTSM)可以进行若干个仿真。所示的所有仿真是使用MinDropIntervalMultiplier的指数计算,其中ExponentialBase=4。对于所有的仿真,将CngThExceedRatio设置为50%。
以下的仿真结果是使用相同的输入数据流和物理层参数,如图10A中所示,其中UDP速率=18kB/s而物理输出速率=16kB/s。
仿真参数:
UDP参数
18 UDP_DR-UDP数据速率(KBytes/sec)
拥塞控制算法参数
4000 Start_CngTh 初始拥塞阈值
1200 DropSizeTh-要丢弃的数据包的最小尺寸
2 MinDropInterval(秒)-丢弃的数据包间的初始最小时间量
0.4375 EstRTT-所估计的RTT
0.5 CngTh_Exceed_Ratio-队列深度可以增长的最大百分比,其中最小丢弃间隔将接近于零
物理层
16 输出数据速率(KB/sec)
从图11A可以看出,现在可以控制队列深度,只有在开始处出现一些过量的排队,其中TCP会话是在慢启动状态。由于没有清空队列,所以队列的输出速率等于物理输出速率就不奇怪了。图11A还示出,在慢启动过程期间,与当TCP处于拥塞控制状态相比,UDP流使用了物理输出速率的较大的百分比,TCP流使用了大约3500kB/s。当UDP速率大于物理输出速率时,由于过多的数据包丢弃TCP拥塞窗口被典型地限制为一段。该小的拥塞窗口基于DBP公式(对于上述仿真,MTUSize/RTT 1450/0.4=3625B/s)限制TCP速率。
图12A中示出的下一个仿真输出是使用与先前相同的DTSM队列管理***,但是这次物理输出速率是从16至8至32kB/s变化的。
仿真参数:
UDP参数
18 UDP_DR-UDP数据速率(KBytes/sec)
拥塞控制算法参数
4000 Start_CngTh 开始时的拥塞阈值
2 MinDropInterval(秒)-丢弃的数据包间的初始最小时间量
0.4375 EstRTT-用于计算最小丢弃间隔所估计的RTT
0.5 CngTh_Exceed_Ratio-队列深度可以增长的最大百分比,其中最小丢弃间隔将接近于零
输出数据速率
16 开始时的速率(KB/sec)
60 改变输出速率的时间(秒)
8 改变的速率(KB/sec)
90 改变输出速率的时间(秒)
32 改变的速率(KB/sec)
上述的仿真结果示出与动态的拥塞阈值信号结合的DTSM附加减少了用于各种物理输出的排队深度。
DTSM方法有两个已知的缺点。第一个缺点是队列管理***在TCP慢启动机制期间会错误地丢弃一个以上数据包。在TCP栈进入拥塞控制状态后,该方法意指通过只丢弃一个数据包而等待TCP栈来响应来工作。第二个缺点是当物理输出速率突然下降时,DTSM方法会错误地丢弃一个以上数据包。物理输出速率的突然下降导致拥塞阈值突然地下降,这依赖于队列的当前深度在那时可以产生当前队列深度远超出拥塞阈值情形。如果使用较大的CngTh_Exceed_Ratio,则可以将该有害的效应最小化。需要CngTh_Exceed_Ratio>100%以排除这两个负面效应,但是当然要以增大队列深度为代价。
为了示出这两个效应,图13A中的下一仿真结果使用与先前相同的DTSM队列管理***,但是这次队列的输入只是TCP数据,没有UDP数据。
仿真参数:
UDP参数
0 UDP_DR-UDP数据速率(KBytes/sec)
拥塞控制算法参数
4000 Start_CngTh 开始时的拥塞阈值
2 最小丢弃间隔(MinDropInterval)(秒)-丢弃的数据包间的初始最小时间量
0.4375 EstRTT-用于计算最小丢弃间隔所估计的RTT
0.5 CngTh_Exceed_Ratio-队列深度可以增长的最大百分比,其中最小丢弃间隔将接近于零
输出数据速率
16 开始时的速率(KB/sec)
60 改变输出速率的时间(秒)
8 改变的速率(KB/sec)
90 改变输出速率的时间(秒)
32 改变的速率(KB/sec)
在上述仿真的~4秒标记处,多个TCP数据包被丢弃,那时TCP处于慢启动状态。这导致了在~7秒标记处的平均队列输出速率的暂时下降。
第二个负面效应在~60秒标记处,其中物理输出速率从16kB/s变化到8kB/s。该时间处我们发现队列管理***错误地丢弃了若干个TCP数据包,其会导致平均队列输出速率的暂时减少。
将CngTh_Exceed_Ratio设置为较大的值会导致过量的排队,但是CngTh_Exceed_Ratio过小将会导致错误地丢弃数据包(如图13中所示)。使用有利地指数等式来计算最小丢弃间隔允许使用较小的CngTh_Exceed_Ratio,但是这仅有助于每一个点。
虽然上述队列管理***使用具有动态拥塞阈值的DTSM,但是还可以使用具有先前所描述的具有动态最小时间间隔和最小数据包间隔***的DTSM***。
Claims (8)
1.一种用于队列缓冲管理的方法,包括
在一个或多个网络装置处接收经由流控制接口传输的互联网协议数据,所述互联网协议数据在数据源装置处生成并被传输至所述一个或多个网络装置;以及
基于指定的标准在所述一个或多个网络装置处选择性地删除所接收的数据的部分,以实现所述互联网协议数据的改善的数据流;
其中,所述指定的标准包括数据通信***的静态和动态参数,其中,所述动态参数包括拥塞阈值、最小时间间隔、最小丢弃数据包尺寸、以及数据协议。
2.根据权利要求1所述的方法,其中,一个或多个所述指定的标准是动态确定的。
3.根据权利要求1所述的方法,其中,一个或多个指定的标准具有动态确定的对应的值。
4.根据权利要求1所述的方法,其中,所生成的数据是被加密的并且所述指定的标准包括数据包尺寸。
5.一种用于队列缓冲管理的设备,包括
网络装置,通信连接至数据源装置,所述网络装置被配置为接收在所述数据源装置处生成的互联网协议数据并基于指定的标准在所述网络装置处选择性地删除所述数据的部分,以实现所述互联网协议数据的改善的数据流,所述互联网协议数据经由流控制接口被传输;
其中,所述指定的标准包括数据通信***的静态和动态参数,其中,所述动态参数包括拥塞阈值、最小时间间隔、最小丢弃数据包尺寸、以及数据协议。
6.根据权利要求5所述的设备,其中,一个或多个所述指定的标准是动态确定的。
7.根据权利要求5所述的设备,其中,一个或多个指定的标准具有动态确定的对应的值。
8.根据权利要求5所述的设备,其中,所生成的数据是被加密的并且所述指定的标准包括数据包尺寸。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/807,240 US20080291833A1 (en) | 2007-05-25 | 2007-05-25 | Method for buffer control for network device |
US11/807,240 | 2007-05-25 | ||
PCT/CA2008/001000 WO2008144902A1 (en) | 2007-05-25 | 2008-05-26 | Method for buffer control for network device |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101682627A CN101682627A (zh) | 2010-03-24 |
CN101682627B true CN101682627B (zh) | 2014-11-26 |
Family
ID=40072291
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200880017500.9A Expired - Fee Related CN101682627B (zh) | 2007-05-25 | 2008-05-26 | 用于网络装置的缓冲控制的方法 |
Country Status (8)
Country | Link |
---|---|
US (1) | US20080291833A1 (zh) |
EP (1) | EP2151116A4 (zh) |
JP (1) | JP5194115B2 (zh) |
KR (1) | KR101141160B1 (zh) |
CN (1) | CN101682627B (zh) |
AU (1) | AU2008255539B2 (zh) |
CA (1) | CA2685439A1 (zh) |
WO (1) | WO2008144902A1 (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5146548B2 (ja) | 2009-02-06 | 2013-02-20 | 富士通株式会社 | パケットバッファ装置及びパケット廃棄方法 |
US7792131B1 (en) * | 2009-03-10 | 2010-09-07 | Cisco Technologies, Inc. | Queue sharing with fair rate guarantee |
JP5640649B2 (ja) * | 2010-10-27 | 2014-12-17 | ソニー株式会社 | データ通信方法及び情報処理装置 |
US8824290B2 (en) * | 2011-01-07 | 2014-09-02 | Qualcomm Incorporated | Downlink flow control using packet dropping to control transmission control protocol (TCP) layer throughput |
US8441927B2 (en) * | 2011-01-13 | 2013-05-14 | Alcatel Lucent | System and method for implementing periodic early discard in on-chip buffer memories of network elements |
US20140237021A1 (en) * | 2013-02-15 | 2014-08-21 | Broadcom Corporation | System and Method for Bandwidth-Delay-Product Decoupler |
DE112013007142T5 (de) * | 2013-06-07 | 2016-04-14 | Apple Inc. | Verwalten anstehender Bestätigungspakete in einer Kommunikationsvorrichtung |
TWI692233B (zh) * | 2018-12-19 | 2020-04-21 | 財團法人工業技術研究院 | 基於用戶資料報協定及傳輸控制協定之協同傳輸方法及傳輸裝置 |
CN114244773A (zh) * | 2020-09-09 | 2022-03-25 | 英业达科技有限公司 | 封包处理***及其封包处理方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6633540B1 (en) * | 1999-07-02 | 2003-10-14 | Nokia Internet Communications, Inc. | Real-time traffic shaper with keep-alive property for best-effort traffic |
CN1531804A (zh) * | 2001-04-09 | 2004-09-22 | ����ɭ�绰�ɷ�����˾ | 控制队列缓冲区的方法 |
CN1910868A (zh) * | 2003-12-23 | 2007-02-07 | 艾利森电话股份有限公司 | 用于控制队列缓冲器的方法及装置 |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4884272A (en) * | 1988-02-10 | 1989-11-28 | Mcconnell Peter R H | Maximum likelihood diversity receiver |
JP3419627B2 (ja) * | 1996-06-11 | 2003-06-23 | 株式会社日立製作所 | ルータ装置 |
US6321338B1 (en) * | 1998-11-09 | 2001-11-20 | Sri International | Network surveillance |
US6453360B1 (en) * | 1999-03-01 | 2002-09-17 | Sun Microsystems, Inc. | High performance network interface |
US6327625B1 (en) * | 1999-11-30 | 2001-12-04 | 3Com Corporation | FIFO-based network interface supporting out-of-order processing |
US6862282B1 (en) * | 2000-08-29 | 2005-03-01 | Nortel Networks Limited | Method and apparatus for packet ordering in a data processing system |
US6856596B2 (en) * | 2000-12-01 | 2005-02-15 | Marconi Communications, Inc. | Approximation of the weighted random early detection buffer admittance algorithm |
WO2002049291A1 (en) * | 2000-12-12 | 2002-06-20 | Nokia Corporation | A method for controlling a stream of data packets in a packet data communication network |
US7042843B2 (en) * | 2001-03-02 | 2006-05-09 | Broadcom Corporation | Algorithm for time based queuing in network traffic engineering |
US7042848B2 (en) * | 2001-05-04 | 2006-05-09 | Slt Logic Llc | System and method for hierarchical policing of flows and subflows of a data stream |
US7194766B2 (en) * | 2001-06-12 | 2007-03-20 | Corrent Corporation | Method and system for high-speed processing IPSec security protocol packets |
US6633835B1 (en) * | 2002-01-10 | 2003-10-14 | Networks Associates Technology, Inc. | Prioritized data capture, classification and filtering in a network monitoring environment |
US7221656B1 (en) * | 2002-06-18 | 2007-05-22 | Nortel Networks Limited | Technique for implementing an admission control scheme for data flows |
US7542471B2 (en) * | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
US7656799B2 (en) * | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
US20070091799A1 (en) * | 2003-12-23 | 2007-04-26 | Henning Wiemann | Method and device for controlling a queue buffer |
WO2005069554A1 (en) * | 2004-01-14 | 2005-07-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and devices for controlling data unit handling |
JP2005229185A (ja) * | 2004-02-10 | 2005-08-25 | Livecom Corp | 伝送装置 |
US20060187836A1 (en) * | 2005-02-18 | 2006-08-24 | Stefan Frey | Communication device and method of prioritizing transference of time-critical data |
US7397781B2 (en) * | 2005-04-18 | 2008-07-08 | Sierra Wireless, Inc. | Configurable multislot class for wireless devices |
US7724660B2 (en) * | 2005-12-13 | 2010-05-25 | Alcatel Lucent | Communication traffic congestion management systems and methods |
-
2007
- 2007-05-25 US US11/807,240 patent/US20080291833A1/en not_active Abandoned
-
2008
- 2008-05-26 AU AU2008255539A patent/AU2008255539B2/en not_active Ceased
- 2008-05-26 EP EP08757137.8A patent/EP2151116A4/en not_active Withdrawn
- 2008-05-26 CA CA002685439A patent/CA2685439A1/en not_active Abandoned
- 2008-05-26 KR KR1020097024504A patent/KR101141160B1/ko not_active IP Right Cessation
- 2008-05-26 CN CN200880017500.9A patent/CN101682627B/zh not_active Expired - Fee Related
- 2008-05-26 WO PCT/CA2008/001000 patent/WO2008144902A1/en active Application Filing
- 2008-05-26 JP JP2010508679A patent/JP5194115B2/ja not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6633540B1 (en) * | 1999-07-02 | 2003-10-14 | Nokia Internet Communications, Inc. | Real-time traffic shaper with keep-alive property for best-effort traffic |
CN1531804A (zh) * | 2001-04-09 | 2004-09-22 | ����ɭ�绰�ɷ�����˾ | 控制队列缓冲区的方法 |
CN1910868A (zh) * | 2003-12-23 | 2007-02-07 | 艾利森电话股份有限公司 | 用于控制队列缓冲器的方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
AU2008255539B2 (en) | 2011-08-18 |
WO2008144902A1 (en) | 2008-12-04 |
JP2010528506A (ja) | 2010-08-19 |
CN101682627A (zh) | 2010-03-24 |
CA2685439A1 (en) | 2008-12-04 |
AU2008255539A1 (en) | 2008-12-04 |
EP2151116A1 (en) | 2010-02-10 |
KR101141160B1 (ko) | 2012-05-02 |
EP2151116A4 (en) | 2013-09-04 |
JP5194115B2 (ja) | 2013-05-08 |
KR20100005721A (ko) | 2010-01-15 |
US20080291833A1 (en) | 2008-11-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101682627B (zh) | 用于网络装置的缓冲控制的方法 | |
US6560199B1 (en) | Band controller and its buffer overflow quenching method | |
Zhang et al. | An implementation and experimental study of the explicit control protocol (XCP) | |
Balakrishnan et al. | The congestion manager | |
US8085781B2 (en) | Bulk data transfer | |
US8004981B2 (en) | Methods and devices for the coordination of flow control between a TCP/IP network and other networks | |
US7724750B2 (en) | Expedited data transmission in packet based network | |
US7817556B2 (en) | Modification of policing methods to make them more TCP-friendly | |
US20100020689A1 (en) | Immediate ready implementation of virtually congestion free guaranteed service capable network : nextgentcp/ftp/udp intermediate buffer cyclical sack re-use | |
US20130294235A1 (en) | System and Method for Controlling Network Congestion | |
KR20040068880A (ko) | 스트리밍 데이터에 대한 리액티브 대역폭 제어 | |
US7428243B2 (en) | Method and system for varying data packet size for controlling bandwidth | |
Ananth et al. | FASTRA–Safe And Secure | |
Kadhum et al. | Congestion-aware TCP-friendly system for multimedia transmission based on UDP | |
AU2011203511B2 (en) | Bulk data transfer | |
US20240048334A1 (en) | Method and apparatus for bandwidth adaptive scheduling in cloud based virtual network functions for traffic over point-to-point overlay tunnels | |
Kühlewind et al. | Implementation and Performance Evaluation of the re-ECN Protocol | |
Dangi et al. | A new congestion control algorithm for high speed networks | |
Li et al. | A rate regulating traffic conditioner for supporting TCP over Diffserv | |
Lee et al. | Congestion control of transmission control protocol based on bandwidth estimation | |
Zou et al. | Performance evaluation of subflow capable SCTP | |
Bagnulo et al. | Design, implementation and validation of a receiver-driven less-than-best-effort transport | |
Dahlberg | A Data Plane native PPV PIE Active Queue Mangement Scheme using P4 on a Programmable Switching ASIC | |
Islam et al. | RFC 8699 Coupled Congestion Control for RTP Media | |
ElAarag et al. | TCP friendly protocols for media streams over heterogeneous wired–wireless networks |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20141126 Termination date: 20190526 |
|
CF01 | Termination of patent right due to non-payment of annual fee |