US6958998B2 - Traffic management in packet-based networks - Google Patents

Traffic management in packet-based networks Download PDF

Info

Publication number
US6958998B2
US6958998B2 US09/901,229 US90122901A US6958998B2 US 6958998 B2 US6958998 B2 US 6958998B2 US 90122901 A US90122901 A US 90122901A US 6958998 B2 US6958998 B2 US 6958998B2
Authority
US
United States
Prior art keywords
packets
packet
service priority
network node
relative service
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, expires
Application number
US09/901,229
Other versions
US20030007454A1 (en
Inventor
Rajeev Shorey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US09/901,229 priority Critical patent/US6958998B2/en
Assigned to INTERNATIONAL BUSINESS reassignment INTERNATIONAL BUSINESS ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SHOREY, RAJEEV
Publication of US20030007454A1 publication Critical patent/US20030007454A1/en
Application granted granted Critical
Publication of US6958998B2 publication Critical patent/US6958998B2/en
Adjusted expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/20Traffic policing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433Allocation of priorities to traffic types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2458Modification of priorities while in transit
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/31Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Definitions

  • the invention relates to traffic management in packet-based networks and relates particularly to the provision of packet-based service differentiation in packet-based networks.
  • U.S. Pat. No. 5,224,099 issued to Corbalis et al on 29 Jun. 1993 discloses a method of queuing and servicing of cell traffic.
  • the described techniques attempt to provide a fair servicing regime that satisfactorily handles different classes of traffic (voice, data etc) which have different quality-of-service priorities, in terms of delay and loss sensitivity.
  • Corbalis et al draw a distinction between bursty and non-bursty cell traffic.
  • Bursty cell traffic is placed in one of a number of subqueues according to a hopcount associated with the respective cell. Each subqueue has a different servicing priority. Minimum bandwidths are respectively allocated to bursty and non-bursty traffic, and spare bandwidth is allocated to cell traffic according to a predefined priority scheme.
  • the use of hopcount information (discussed in Corbalis et al), generally, has no bearing on the underlying congestion on the network. Accordingly, the use of hopcount information, as disclosed in Corbalis et al, does not provide a particularly advantageous way in which to address network congestion.
  • RED Random Early Drop
  • RED and related algorithms are probabilistic and stateless, as packets are indiscriminately dropped at a certain rate, depending on the current average queue length. This approach is relatively unsophisticated, and accordingly does not make optimal use of network resources.
  • Packet-based traffic management in packet networks can be advantageously improved by using information associated with individual packets.
  • Packets are implicitly differentiated into connections of different types, based on information derived from the individual packets. It may be considered that fields associated with individual packets explicitly or implicitly convey connection characteristics associated with that packet. Connections are distinguished into different types based on a measure (a metric or a characteristic) that at least partly reflects the duration (for example, end-to-end packet delay) of packet transmission associated with the connection.
  • a connection characteristic can be inferred from a field which has a numerical value representative of a particular metric. It is preferred that this representative value be correlated with the amount of network resources consumed by the respective packet in the packet-based network.
  • RTT Random Trip Time
  • hopcount may be used as a representative value which is combined with duration information such as RTT.
  • hopcount can be determined by comparing the current value for the TTL (Time to Live) field in the packet header information with the initial TTL value.
  • RED routers/gateways are inherently biased against packet flows with a large RTT. Accordingly, at congested network nodes, dropping packets from long connections (that is, with high RTT) adversely affects the throughput associated with the packet flow of such connections, more so than for shorter connections. Further, long connections consume correspondingly greater network resources than short connections and, as a result, there is greater wastage of network resources if packets from long connections are dropped. In this context, long connections can be thought of as being characterised by a large RTT value and, additionally, a relatively high “hopcount”.
  • hopcount and RTT may be combined in a predetermined manner to provide an empirically representative measure of the amount of network resources consumed by particular packets, for a given type of network topology and traffic flow characteristics. Hopcount and RTT can for some networks provide a generally reliable indication of the characteristics of a connection with which the packet is associated.
  • a fair and efficient regime for queuing packets through a network node allows for improved network usage.
  • the priority of packets is adjusted at network nodes in response to information associated with packets which implies certain connection characteristics, and the packet drop probability correspondingly adjusted, based on the assigned priority of the packet.
  • FIGS. 1 and 2 are flowcharts which each represent steps involved in performing steps of a traffic management algorithm for a packet-based network.
  • FIG. 3 is a schematic representation of a generic architecture for a network hardware element with which the algorithm represented in FIGS. 1 and 2 can be implemented.
  • the described techniques can be implemented at a network node (for example, a gateway or router) which receives and forwards packets as they are passed through the packet-based network.
  • a network node for example, a gateway or router
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • a host transmits a TCP packet to a peer, it must wait a period of time for an acknowledgment by reply. If the acknowledgment reply does not come within an expected period, the packet is assumed to have been lost and the data is retransmitted. However, how long does one wait before retransmitting the packet? Over an Ethernet connection, no more than a few microseconds should be needed for a reply. If the traffic must flow over the wide-area Internet, a second or two might be reasonable during peak utilization times.
  • RTT Round-Trip Time
  • a router typically has multiple packet connections passing through the router. Packets can be differentiated as being associated with “long” connections or “short” connections, based on packet header information.
  • IP packets in TCP networks have (at layer 3 ) a TTL (time to live) field.
  • a RTT (Round Trip Time) field can be transmitted by sources using, for example, the TCP option field or IP option field. As packets pass through the network node, these fields can be used to differentiate packets as being associated with long or short connections.
  • TTL time to live
  • RTT Red Trip Time
  • RTT is fundamental to timeout and retransmission functions in TCP.
  • RTT experienced on a given connection for a TCP connection is the estimated time taken for a packet to reach its destination, and the corresponding acknowledgment return to the source. As routes or congestion can change over time, these times are monitored and RTT modified if warranted, as noted above.
  • the RTT can be used to differentiate different connections at a particular network node.
  • the TCP option field may be used by the sender to send the RTT of the TCP connection.
  • the RTT values can be sent periodically within a predetermined period. In either case, even if a value of RTT is not included with each packet, a value can be inferred by correlating other characteristics (for example, source and destination IP addresses) with a packet for which RTT is known.
  • a running average RTT value for all packets is maintained at a network node, as well as a record of prevailing maximum and minimum values. For each arriving packet, a comparison is made between the RTT for that packet and the average. If the RTT is greater than average, the packet can be assigned a greater relative priority. If the RTT is lower than average, the packet can be assigned a lower relative priority.
  • the TTL field in an IP header sets an upper limit on the number of network routers through which a datagram can pass, thus limiting the potential lifetime of the datagram.
  • the TTL field is initialised by the sender to some value. Different operating systems can assign different default TTL values, and TTL values can also vary from one version of TCP to another. Further, TTL values can be varied by appropriate network applications.
  • the TTL per se is not useful in determining the implied characteristics of a connection with which the packet is associated, as there is no reliable indication of the initial value of the TTL value.
  • the “hopcount” that is, the number of routers through which the packet has passed to reach the particular network node
  • the “hopcount” can be determined by comparing the TTL field value in the packet header of the packet, with the initial TTL value stored in the packet header.
  • the initial TTL value is stored in the IP option field.
  • hopcount is a relatively reliable indication of the connection with which the packet is associated. In other words, the hopcount can be used to meaningfully differentiate packet connections.
  • the calculated hopcount is stored in a register and indicates the number of nodes through which the packet has passed before arriving at the present network node.
  • a running average hopcount is maintained at the node for all packets passing through that node.
  • a record is also maintained of the maximum and minimum values of hopcount for packets through the node.
  • hopcount information For each packet that passes through the node, hopcount information can be combined with other transmission duration information (such as RTT) to determine the relative service priority assigned to respective packets.
  • RTT transmission duration information
  • RTT is used in conjunction with hopcount to determine whether the packet is associated with a long or short connection.
  • a path through the network may have a low hopcount, but a large RTT associated with the packet, due to congestion.
  • another path may have a high hopcount but a low RTT, if there is little or no congestion.
  • hopcount alone is not used to prioritize packets.
  • Relative service priority can be more finely graded than simply “lower” or “higher” priority.
  • a whole range of statistical techniques and binning algorithms can be brought to bear on these and/or other packet header information values to assign relative priorities to packets passing through a network node.
  • FIG. 1 illustrates the steps that occur when RTT values are used to prioritise network traffic.
  • the network node receives incoming packets from the network.
  • the network node inspects the packet information associated with the incoming packets, in step 120 .
  • the values for the average value, maximum value and minimum value of the RTT are updated using the new values of RTT taken from the incoming packets. These values are respectively maintained as Avg — RTT, Max — RTT and Min — RTT.
  • step 140 the value of RTT for each incoming packet is compared with the corresponding average value of RTT. On this basis, packets are assigned a relative service priority in step 150 . That is, if the packet has a greater than average RTT, then the packet is assigned a higher relative service priority, though if the packet has a lower than average RTT, then the packet is assigned a lower relative service priority.
  • the node When there is no packet congestion at a network node, the node operates in its usual manner. That is, all incoming packets are admitted to a packet buffer maintained for the purpose of temporarily storing then forwarding incoming packets.
  • packets with a lower assigned service priority are dropped in preference to packets with a higher assigned service priority.
  • the packets are typically dropped before being admitted to the buffer maintained at the network node. (Packets can be dropped once stored in the buffer, but providing such functionality results in higher implementation overloads, involving pointer manipulations.)
  • a FIFO algorithm is used to process packets stored in the buffer at the network node.
  • Other scheduling algorithms can be used, if considered appropriate or desirable, though more sophisticated schemes necessarily involve additional complexity.
  • packets can be “marked” rather than dropped. Packets are “marked” on the same basis that they are “dropped”. A marked packet, once it eventually returns to the node from which it was originally sent, is recognised as marked. In response, the source node shrinks the TCP window thereby possibly reducing congestion at the bottleneck node.
  • the buffer is essentially a queue in which packets are processed in a FIFO manner.
  • FIG. 2 is a flowchart representing the steps which occur once a relative service priority has been assigned, and before packets are queued in a buffer.
  • a packet and the associated relative service priority is received in step 210 .
  • the associated relative service priority is determined as described above with reference to FIG. 1 .
  • a check of the queue length is made (that is, the number of packets stored in the buffer) in step 220 .
  • a record of the average queue length, AvgQ is maintained, for the purpose described below. It is determined at this point, in step 230 , whether the queue is congested.
  • AvgQ average queue length at the node, AvgQ
  • Min — q minimum predetermined threshold
  • Max — q maximum predetermined threshold
  • AvgQ is between these two predetermined thresholds; that is: Min — q ⁇ AvgQ ⁇ Max — q, then the queue is partly congested.
  • step 240 the packet is admitted in step 240 , and the process repeats from step 210 .
  • the packet is dropped in step 270 and similarly the process repeats from step 210 .
  • a random process is then implemented at the network node to determine whether the packet is to be dropped. Packets with higher relative service priority use a lower Max — p and thus have a lower calculated drop probability and are thus dropped less frequently.
  • the described techniques are implemented on network hardware elements that are located at network nodes.
  • the network hardware or network node can be, for example, a router, gateway or any other form of programmable network hardware through which packets pass in a packet-based network.
  • the methods described above may be implemented in a router that receives packets from the network, and passes the packets on, after appropriate processing.
  • the network hardware executes software code that allows the network hardware to function as intended.
  • FIG. 3 A generic architecture for a suitable network hardware element is schematically represented in FIG. 3 , for the case of a router.
  • the router has an input port 310 , an output port 360 , switching fabric 320 , a processor 330 , and associated registers 340 and memory 350 .
  • the input port 310 interfaces to the switching fabric 320 , which is in turn interfaced to the output port 360 .
  • Incoming packets in the input port 310 are interrogated by the processor 330 , which is connected to the switching fabric 320 .
  • the processor 330 to which storage registers 340 and a memory 350 are operatively connected, executes a computer software program that is essentially control program stored in the memory 350 .
  • the registers 340 stores values obtained from the processor 330 , during computation by the processor 330 .
  • the processor 330 operates the switching fabric 320 in accordance with the control program, for the ultimate purpose of routing incoming packets on the input port 310 , through the switching fabric 320 , to outgoing packets on the output port 360 .
  • the processor 330 maintains a buffer of packets scheduled for output on the output port 360 . Due to congestion, packets are queued at the output port 360 pending transmission in the manner described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Providing packet-based service differentiation on packet-based networks involves first determining information associated with packets as a basis for inferring connection characteristics associated with the respective packet, as the packets pass though a particular network node. Statistical measures based on numerical values of, for example, Round Trip Time (RTT), is used to characterize connections as being, in this case “long” or “short”. “Long” connections are given a higher priority than “short” connections. Accordingly, the assigned priority associated with particular packets can be used to adjust drop probabilities for those packets.

Description

FIELD OF THE INVENTION
The invention relates to traffic management in packet-based networks and relates particularly to the provision of packet-based service differentiation in packet-based networks.
BACKGROUND
For a telecommunications network such as an ATM network, U.S. Pat. No. 5,224,099 issued to Corbalis et al on 29 Jun. 1993 discloses a method of queuing and servicing of cell traffic. The described techniques attempt to provide a fair servicing regime that satisfactorily handles different classes of traffic (voice, data etc) which have different quality-of-service priorities, in terms of delay and loss sensitivity.
Corbalis et al draw a distinction between bursty and non-bursty cell traffic. Bursty cell traffic is placed in one of a number of subqueues according to a hopcount associated with the respective cell. Each subqueue has a different servicing priority. Minimum bandwidths are respectively allocated to bursty and non-bursty traffic, and spare bandwidth is allocated to cell traffic according to a predefined priority scheme. The use of hopcount information (discussed in Corbalis et al), generally, has no bearing on the underlying congestion on the network. Accordingly, the use of hopcount information, as disclosed in Corbalis et al, does not provide a particularly advantageous way in which to address network congestion.
In packet-based computer networks, one widely used congestion avoidance algorithm is referred to as RED (Random Early Drop). According to this algorithm, the network drops packets when the average queue length at a network node, such as a router, is within a predetermined range.
The operation of RED and related algorithms is probabilistic and stateless, as packets are indiscriminately dropped at a certain rate, depending on the current average queue length. This approach is relatively unsophisticated, and accordingly does not make optimal use of network resources.
The above described existing techniques do not adequately or, in all cases, appropriately conserve network resources. Accordingly, a clear need exists for an improved manner of handling network traffic which at least attempts to address these and other limitations associated with existing techniques.
SUMMARY
Packet-based traffic management in packet networks can be advantageously improved by using information associated with individual packets. Packets are implicitly differentiated into connections of different types, based on information derived from the individual packets. It may be considered that fields associated with individual packets explicitly or implicitly convey connection characteristics associated with that packet. Connections are distinguished into different types based on a measure (a metric or a characteristic) that at least partly reflects the duration (for example, end-to-end packet delay) of packet transmission associated with the connection.
A connection characteristic can be inferred from a field which has a numerical value representative of a particular metric. It is preferred that this representative value be correlated with the amount of network resources consumed by the respective packet in the packet-based network.
For TCP/IP networks, one such field that can be used is the value of RTT (Round Trip Time). This value, if explicitly included in the packet header information for IP packets, estimates the round trip time associated with the packet as it travels between source and destination, and as the corresponding acknowledgment returns from the destination back to the source.
Other measures can also be additionally used, either taken directly from packet header information values, or derived therefrom. For example, hopcount may be used as a representative value which is combined with duration information such as RTT. In a TCP/IP network, hopcount can be determined by comparing the current value for the TTL (Time to Live) field in the packet header information with the initial TTL value.
It is recognised that RED routers/gateways are inherently biased against packet flows with a large RTT. Accordingly, at congested network nodes, dropping packets from long connections (that is, with high RTT) adversely affects the throughput associated with the packet flow of such connections, more so than for shorter connections. Further, long connections consume correspondingly greater network resources than short connections and, as a result, there is greater wastage of network resources if packets from long connections are dropped. In this context, long connections can be thought of as being characterised by a large RTT value and, additionally, a relatively high “hopcount”.
Statistical measures of these values are typically maintained, so that individual packets can be classified as having, for example, below average or above average values.
More sophisticated metrics, which take into account one or more such values, can be derived and applied accordingly. For example, hopcount and RTT may be combined in a predetermined manner to provide an empirically representative measure of the amount of network resources consumed by particular packets, for a given type of network topology and traffic flow characteristics. Hopcount and RTT can for some networks provide a generally reliable indication of the characteristics of a connection with which the packet is associated.
A fair and efficient regime for queuing packets through a network node allows for improved network usage. The priority of packets is adjusted at network nodes in response to information associated with packets which implies certain connection characteristics, and the packet drop probability correspondingly adjusted, based on the assigned priority of the packet.
While various techniques and arrangements are described herein in relation to “packets”, it is understood that these techniques and arrangements are also applicable to other connectionless data arrangements using, for example, “cells” and that packets and associated terminology can be used interchangeably with any such other corresponding terms.
DESCRIPTION OF DRAWINGS
FIGS. 1 and 2 are flowcharts which each represent steps involved in performing steps of a traffic management algorithm for a packet-based network.
FIG. 3 is a schematic representation of a generic architecture for a network hardware element with which the algorithm represented in FIGS. 1 and 2 can be implemented.
DETAILED DESCRIPTION
Techniques for packet management in a packet-based network are described herein. The described techniques can be implemented at a network node (for example, a gateway or router) which receives and forwards packets as they are passed through the packet-based network.
The Transmission Control Protocol (TCP) provides reliable, stream-oriented connections on packet-based networks. The Internet, and Ethernet implementations, use TCP/IP protocols that are based on TCP, which is in turn based on the Internet Protocol (IP). When a host transmits a TCP packet to a peer, it must wait a period of time for an acknowledgment by reply. If the acknowledgment reply does not come within an expected period, the packet is assumed to have been lost and the data is retransmitted. However, how long does one wait before retransmitting the packet? Over an Ethernet connection, no more than a few microseconds should be needed for a reply. If the traffic must flow over the wide-area Internet, a second or two might be reasonable during peak utilization times.
However, as this reasonable expected wait time is variable, TCP implementations monitor the normal exchange of data packets and develop an estimate of the time that should elapse before an acknowledgment is received. This estimate is termed the Round-Trip Time (RTT) estimation. RTT estimates are one of the most important performance parameters in a TCP exchange, especially as all TCP implementations typically experience packet drops due to congestion and must accordingly retransmit dropped packets, irrespective of link quality. If the RTT estimate is too low, packets are retransmitted unnecessarily. If the RTT estimate is too high, the network connection can remain idle unnecessarily, while the host waits to timeout.
A router typically has multiple packet connections passing through the router. Packets can be differentiated as being associated with “long” connections or “short” connections, based on packet header information. In this respect, IP packets in TCP networks have (at layer 3) a TTL (time to live) field. Further, a RTT (Round Trip Time) field can be transmitted by sources using, for example, the TCP option field or IP option field. As packets pass through the network node, these fields can be used to differentiate packets as being associated with long or short connections. Each of these packet header information fields, and their use, is discussed further below.
RTT Field Information
RTT is fundamental to timeout and retransmission functions in TCP. RTT experienced on a given connection for a TCP connection is the estimated time taken for a packet to reach its destination, and the corresponding acknowledgment return to the source. As routes or congestion can change over time, these times are monitored and RTT modified if warranted, as noted above.
The RTT can be used to differentiate different connections at a particular network node. The TCP option field may be used by the sender to send the RTT of the TCP connection. As RTT values for a connection do not change very frequently with time, the RTT values can be sent periodically within a predetermined period. In either case, even if a value of RTT is not included with each packet, a value can be inferred by correlating other characteristics (for example, source and destination IP addresses) with a packet for which RTT is known.
A running average RTT value for all packets is maintained at a network node, as well as a record of prevailing maximum and minimum values. For each arriving packet, a comparison is made between the RTT for that packet and the average. If the RTT is greater than average, the packet can be assigned a greater relative priority. If the RTT is lower than average, the packet can be assigned a lower relative priority.
TTL Field Information
The TTL field in an IP header sets an upper limit on the number of network routers through which a datagram can pass, thus limiting the potential lifetime of the datagram. The TTL field is initialised by the sender to some value. Different operating systems can assign different default TTL values, and TTL values can also vary from one version of TCP to another. Further, TTL values can be varied by appropriate network applications.
Accordingly, the TTL per se is not useful in determining the implied characteristics of a connection with which the packet is associated, as there is no reliable indication of the initial value of the TTL value. Instead, however, the “hopcount” (that is, the number of routers through which the packet has passed to reach the particular network node) can be determined by comparing the TTL field value in the packet header of the packet, with the initial TTL value stored in the packet header. The initial TTL value is stored in the IP option field.
This gives the number of “hops” (routers) through which the packet has passed. As packet routes through the Internet change infrequently, the hopcount is a relatively reliable indication of the connection with which the packet is associated. In other words, the hopcount can be used to meaningfully differentiate packet connections.
The calculated hopcount is stored in a register and indicates the number of nodes through which the packet has passed before arriving at the present network node. A running average hopcount is maintained at the node for all packets passing through that node. A record is also maintained of the maximum and minimum values of hopcount for packets through the node.
For each packet that passes through the node, hopcount information can be combined with other transmission duration information (such as RTT) to determine the relative service priority assigned to respective packets.
Assigned Priority and Allocated Drop Probability
In the two cases discussed above of TTL and RTT, packets are only classified as being of higher or lower priority, depending on the inference of whether the packet is associated with a longer or shorter connection respectively.
Desirably, RTT is used in conjunction with hopcount to determine whether the packet is associated with a long or short connection. A path through the network may have a low hopcount, but a large RTT associated with the packet, due to congestion. Similarly, another path may have a high hopcount but a low RTT, if there is little or no congestion. As there appears to be little correlation between hopcount and RTT in the Internet, it is advantageous that hopcount alone is not used to prioritize packets.
Relative service priority can be more finely graded than simply “lower” or “higher” priority. A whole range of statistical techniques and binning algorithms can be brought to bear on these and/or other packet header information values to assign relative priorities to packets passing through a network node.
EXAMPLE
FIG. 1 illustrates the steps that occur when RTT values are used to prioritise network traffic.
In step 110, the network node receives incoming packets from the network. The network node inspects the packet information associated with the incoming packets, in step 120. In step 130, the values for the average value, maximum value and minimum value of the RTT are updated using the new values of RTT taken from the incoming packets. These values are respectively maintained as AvgRTT, MaxRTT and MinRTT.
In step 140, the value of RTT for each incoming packet is compared with the corresponding average value of RTT. On this basis, packets are assigned a relative service priority in step 150. That is, if the packet has a greater than average RTT, then the packet is assigned a higher relative service priority, though if the packet has a lower than average RTT, then the packet is assigned a lower relative service priority.
When there is no packet congestion at a network node, the node operates in its usual manner. That is, all incoming packets are admitted to a packet buffer maintained for the purpose of temporarily storing then forwarding incoming packets.
However, when there is congestion detected at the node, packets with a lower assigned service priority are dropped in preference to packets with a higher assigned service priority. The packets are typically dropped before being admitted to the buffer maintained at the network node. (Packets can be dropped once stored in the buffer, but providing such functionality results in higher implementation overloads, involving pointer manipulations.)
Most simply, a FIFO algorithm is used to process packets stored in the buffer at the network node. Other scheduling algorithms can be used, if considered appropriate or desirable, though more sophisticated schemes necessarily involve additional complexity.
In some implementations, packets can be “marked” rather than dropped. Packets are “marked” on the same basis that they are “dropped”. A marked packet, once it eventually returns to the node from which it was originally sent, is recognised as marked. In response, the source node shrinks the TCP window thereby possibly reducing congestion at the bottleneck node.
Drop Probability
As noted above, some packets are dropped before being admitted to a buffer. The buffer is essentially a queue in which packets are processed in a FIFO manner.
FIG. 2 is a flowchart representing the steps which occur once a relative service priority has been assigned, and before packets are queued in a buffer.
A packet and the associated relative service priority is received in step 210. The associated relative service priority is determined as described above with reference to FIG. 1. A check of the queue length is made (that is, the number of packets stored in the buffer) in step 220. In this respect, a record of the average queue length, AvgQ, is maintained, for the purpose described below. It is determined at this point, in step 230, whether the queue is congested.
If the average queue length at the node, AvgQ, is less than a minimum predetermined threshold, Minq, then the queue is not congested. If the average queue length at the node, AvgQ, is greater than a maximum predetermined threshold, Maxq, then the queue is congested. If AvgQ is between these two predetermined thresholds; that is: Minq<AvgQ<Maxq, then the queue is partly congested.
If the queue is not congested, the packet is admitted in step 240, and the process repeats from step 210. Similarly, if the queue is congested, the packet is dropped in step 270 and similarly the process repeats from step 210.
If the queue is partly congested, a drop probability Pdrop, is calculated for the packet, as follows:
P drop=Maxp (MaxRTT−AvgRTT)/(MaxRTT−MinRTT)
In the expression above for Pdrop, the relevant terms are as follows:
    • Maxp is a predetermined maximum drop probability, which is adjusted as required for packets of different relative service priority.
    • MaxRTT is the maximum value of RTT for packets for a particular “connection”.
    • MinRTT is the minimum value of RTT for packets for a particular “connection”.
    • AvgRTT is the average value of RTT for packets for a particular “connection”.
A random process is then implemented at the network node to determine whether the packet is to be dropped. Packets with higher relative service priority use a lower Maxp and thus have a lower calculated drop probability and are thus dropped less frequently.
The converse applies to packets with lower relative service priority, which have a higher Maxp and are thus sacrificially dropped to reduce queue congestion, while intelligently conserving network resources. That is, lower service priority packets (such as those with a relatively low average RTT) consume less network resources than higher service priority packets. Accordingly, a lower overall network performance penalty is paid by the network as a whole, if such lower service priority packets are preferentially dropped instead of higher service priority packets.
Once the packet is processed, by dropping the packet or admitting the packet to the buffer, the process returns again to step 210.
Network Hardware
The described techniques are implemented on network hardware elements that are located at network nodes. In this context, the network hardware or network node can be, for example, a router, gateway or any other form of programmable network hardware through which packets pass in a packet-based network.
In a TCP/IP network, the methods described above may be implemented in a router that receives packets from the network, and passes the packets on, after appropriate processing. In this respect, the network hardware executes software code that allows the network hardware to function as intended.
A generic architecture for a suitable network hardware element is schematically represented in FIG. 3, for the case of a router.
The router has an input port 310, an output port 360, switching fabric 320, a processor 330, and associated registers 340 and memory 350. The input port 310 interfaces to the switching fabric 320, which is in turn interfaced to the output port 360. Incoming packets in the input port 310 are interrogated by the processor 330, which is connected to the switching fabric 320.
The processor 330, to which storage registers 340 and a memory 350 are operatively connected, executes a computer software program that is essentially control program stored in the memory 350. The registers 340 stores values obtained from the processor 330, during computation by the processor 330. The processor 330 operates the switching fabric 320 in accordance with the control program, for the ultimate purpose of routing incoming packets on the input port 310, through the switching fabric 320, to outgoing packets on the output port 360.
The processor 330 maintains a buffer of packets scheduled for output on the output port 360. Due to congestion, packets are queued at the output port 360 pending transmission in the manner described above.
It is understood that various alterations and modifications to the techniques and arrangements described can be made, as would be apparent to one skilled in the art.

Claims (28)

1. A method of handling packet traffic on a packet-based network, the method comprising:
receiving, at a network node, a flow of packets from the packet-based network;
determining, for each of the received packets, a metric at least partly based on the duration of transmission for the received packet;
calculating one or more statistical measures associated with values of said metric for the received packets, wherein the statistical measures include an average value;
assigning, to each of the packets, a relative service priority on the basis of the metric; and
queuing one or more of the packets in a queue and transmitting the queued packets from the network node dynamically allocating a packet drop probability for one or more of the packets, based on the assigned relative service priority for the respective packets.
2. The method as claimed in claim 1, further comprising preferentially dropping packets that have a lower relative service priority in favor of packets that have a greater relative service priority, prior to the step of queuing of one or more of the packets.
3. The method as claimed in claim 1, further comprising marking packets that have a lower relative service priority, prior to the queuing of one or more of the packets.
4. The method as claimed in claim 1, further comprising dynamically allocating a packet drop probability occurs, prior to the queuing of one or more packets, wherein packets with a higher relative service priority are allocated a lower packet drop probability and packets with a lower relative service priority are allocated a higher packet drop probability.
5. The method as claimed in claim 4, wherein said dynamically allocating a packet drop probability is preformed if an avenge number of queued packets, at the network node, falls between maximum and minimum predetermined thresholds.
6. The method as claimed in claim 5, further comprising dropping packets if an average number of queued packets, at the network node, exceeds the maximum predetermined threshold.
7. The method as claimed in claim 5, further comprising admitting packets if an average number of queued packets, at the network node, falls below the minimum predetermined threshold.
8. The method as claimed in claim 1, wherein said metric comprises the value of time taken by the packet to traverse the network from the source to destination, and the packet's corresponding acknowledgment to traverse the network from the destination to source.
9. The method as claimed in claim 1, wherein said metric incorporates a hopcount representative of the number of nodes traversed by the packet from source of the packet to the network node.
10. The method as claimed in claim 9, wherein the statistical measures further include a maximum value and a minimum value.
11. The method as claimed in claim 9, wherein two classes of relative service priority, comprising a higher relative service priority and a lower relative service priority, are assigned to the received packets depending on a comparison of the metric with its corresponding average value for the received packets.
12. The method as claimed in claim 1, wherein the packet-based network transmits internet protocol (IP) packets.
13. The method as claimed in claim 12, wherein the packet-based network uses the transmission connection protocol (TCP).
14. The method as claimed in claim 13, wherein the metric comprises the value at the round trip time (RTT) field in the TCP packet header.
15. A method of handling packet traffic on a packet-based network, the method comprising steps of:
receiving, at a network node, a flow of packets from the packet-based network;
inferring, for each of the received packets, a connection characteristic at least partly representative of the duration of transmission for the received packet;
assigning, to each of the packets, a relative service priority on the basis of the inferred connection characteristic;
dynamically allocating a packet drop probability for one or more of the packets, based on the results of the assigned relative service priority; and
queuing one or more of the packets in a queue and transmitting the queued packets from the network node.
16. The method as claimed in claim 15, further comprising preferentially dropping packets that have a lower relative service priority in favor of packets that have a greater relative service priority, prior to the queuing of one or more of the packets.
17. The method as claimed in claim 16, further comprising marking packets that have a lower relative service priority, prior to the queuing of one or more of the packets.
18. The method as claimed in claim 15, wherein packets with a higher relative service priority are allocated a lower packet drop probability and packets with a lower relative service priority are allocated a higher packet drop probability.
19. The method as claimed in claim 18, wherein said dynamically allocating a packet drop probability is preformed if an average number of queued packets, at the network node, falls between maximum and minimum predetermined thresholds.
20. The method as claimed in claim 19, further comprising dropping packets if an average number of queued packets, at the network node, exceeds the maximum predetermined threshold.
21. The method as claimed in claim 19, further comprising admitting packets if an average number of queued packets, at the network node, falls below the minimum predetermined threshold.
22. The method as claimed in claim 18, wherein a plurality of different classes of relative service priority are available to be assigned to the received packets depending upon the identity of the connection characteristic fir respective packets.
23. The method as claimed in claim 15, wherein the packet-based network transmits internet protocol (IP) packets.
24. The method as claimed in claim 15, wherein the packet-based network uses the transmission connection protocol (TCP).
25. A network node apparatus for handling packet traffic on a packet-based network, said apparatus including:
means for receiving, at a network node, a flow of packets from the packet-based network;
means for determining, for each of the received packets, a metric at least partly based the duration of transmission for the received packet;
means for comparing, for each of the received packets, said metric with a corresponding reference value;
means for assigning, to each of the packets, a relative service priority on the basis of the comparison;
means for dynamically allocating a packet drop probability for one or more of the packets, based on the results of the assigned relative service priority; and
means for queuing one or more of the packets in a queue and transmitting the queued packets from the network node.
26. A network node apparatus for handling packet traffic on a packet-based network, said apparatus including:
means for receiving, at a network node, a flow of packets from the packet-based network;
means for inferring, for each of the received packets, a connection characteristic at least partly representative of the duration of transmission for the received packet;
means for assigning, to each of the packets, a relative service priority on the basis of the inferred connection characteristic;
means for dynamically allocating a packet drop probability for one or more of the packets, based on the results of the assigned relative service priority; and
means for queuing one or more of the packets in a queue and transmitting the queued packets from the network node.
27. A computer software program, recorded on a medium and capable of execution by computing means able to interpret the computer software program, for handling packet traffic on a packet-based network, said computer software program comprising:
code means for receiving, at a network node, a flow of packets from the packet-based network;
code means for determining, for each of the received packets, a metric at least partly based the duration of transmission for the received packet;
code means for comparing, for each of the received packets, said metric with a corresponding reference value;
code means for assigning, to each of the packets, a relative service priority on the basis of the comparison;
code means for dynamically allocating a packet drop probability for one or more of the packets, based on the results of the assigned relative service priority; and
code means for queuing one or more of the packets in a queue and transmitting the queued packets from the network node.
28. A computer software program, recorded on a medium and capable of execution by computing means able to interpret the computer software program, for handling packet traffic on a packet-based network, said computer software program comprising:
code means for receiving, at a network node, a flow of packets from the packet-based network;
code means for inferring, for each of the received packets, a connection characteristic at least partly representative of the duration of transmission for the received packet;
code means for assigning, to each of the packets, a relative service priority on the basis of the inferred connection characteristic;
code means for dynamically allocating a packet drop probability for one or more of the packets, based on the results of the assigned relative service priority; and
code means for queuing one or more of the packets in a queue and transmitting the queued packets from the network node.
US09/901,229 2001-07-09 2001-07-09 Traffic management in packet-based networks Expired - Fee Related US6958998B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/901,229 US6958998B2 (en) 2001-07-09 2001-07-09 Traffic management in packet-based networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/901,229 US6958998B2 (en) 2001-07-09 2001-07-09 Traffic management in packet-based networks

Publications (2)

Publication Number Publication Date
US20030007454A1 US20030007454A1 (en) 2003-01-09
US6958998B2 true US6958998B2 (en) 2005-10-25

Family

ID=25413787

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/901,229 Expired - Fee Related US6958998B2 (en) 2001-07-09 2001-07-09 Traffic management in packet-based networks

Country Status (1)

Country Link
US (1) US6958998B2 (en)

Cited By (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030048791A1 (en) * 2001-09-12 2003-03-13 Alcatel Method and apparatus for differentiating service in a data network
US20040151179A1 (en) * 2003-01-31 2004-08-05 Andre Michael R.. Methods and apparatus to limit transmission of data to a localized area
US20060069804A1 (en) * 2004-08-25 2006-03-30 Ntt Docomo, Inc. Server device, client device, and process execution method
US20060088024A1 (en) * 2004-10-27 2006-04-27 Rockwell Electronic Commerce Technologies, Llc Method and apparatus for internet protocol transaction routing
US20060218620A1 (en) * 2005-03-03 2006-09-28 Dinesh Nadarajah Network digital video recorder and method
US20060227706A1 (en) * 2002-03-01 2006-10-12 Bellsouth Intellectual Property Corp. System and method for delay-based congestion detection and connection admission control
US20070058559A1 (en) * 2005-09-15 2007-03-15 Sharp Laboratories Of America, Inc. Method and system of assigning priority to detection messages
US20080181126A1 (en) * 2006-11-29 2008-07-31 Alain Durand Methods and a device for secure distance calculation in communication networks
US20080249961A1 (en) * 2007-03-22 2008-10-09 Harkness David H Digital rights management and audience measurement systems and methods
US20080294647A1 (en) * 2007-05-21 2008-11-27 Arun Ramaswamy Methods and apparatus to monitor content distributed by the internet
US20090097483A1 (en) * 2007-10-15 2009-04-16 Canon Kabushiki Kaisha Method and device for transmitting data
US7636321B1 (en) * 2003-05-12 2009-12-22 Sprint Communications Company L.P. Method and system for measuring round-trip time of packets in a communications network
US20100046927A1 (en) * 2008-08-20 2010-02-25 At&T Intellectual Property I, L.P. System and Method for Retrieving a Previously Transmitted Portion of Television Program Content
US7684347B2 (en) 2004-12-23 2010-03-23 Solera Networks Method and apparatus for network packet capture distributed storage system
US8521732B2 (en) 2008-05-23 2013-08-27 Solera Networks, Inc. Presentation of an extracted artifact based on an indexing technique
US8625642B2 (en) 2008-05-23 2014-01-07 Solera Networks, Inc. Method and apparatus of network artifact indentification and extraction
US8666985B2 (en) 2011-03-16 2014-03-04 Solera Networks, Inc. Hardware accelerated application-based pattern matching for real time classification and recording of network traffic
US8849991B2 (en) 2010-12-15 2014-09-30 Blue Coat Systems, Inc. System and method for hypertext transfer protocol layered reconstruction
US9083635B1 (en) * 2010-10-04 2015-07-14 Adtran, Inc. Enqueue policing systems and methods
US9935851B2 (en) 2015-06-05 2018-04-03 Cisco Technology, Inc. Technologies for determining sensor placement and topology
US9967158B2 (en) 2015-06-05 2018-05-08 Cisco Technology, Inc. Interactive hierarchical network chord diagram for application dependency mapping
US10033766B2 (en) 2015-06-05 2018-07-24 Cisco Technology, Inc. Policy-driven compliance
US10033602B1 (en) 2015-09-29 2018-07-24 Amazon Technologies, Inc. Network health management using metrics from encapsulation protocol endpoints
US10044581B1 (en) 2015-09-29 2018-08-07 Amazon Technologies, Inc. Network traffic tracking using encapsulation protocol
US10089099B2 (en) 2015-06-05 2018-10-02 Cisco Technology, Inc. Automatic software upgrade
US10116559B2 (en) 2015-05-27 2018-10-30 Cisco Technology, Inc. Operations, administration and management (OAM) in overlay data center environments
US20180331922A1 (en) * 2017-05-12 2018-11-15 Pragati Kumar Dhingra Methods and systems for time-based binning of network traffic
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US10171357B2 (en) 2016-05-27 2019-01-01 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10177977B1 (en) 2013-02-13 2019-01-08 Cisco Technology, Inc. Deployment and upgrade of network devices in a network environment
CN109474538A (en) * 2018-12-29 2019-03-15 北京达佳互联信息技术有限公司 A kind of data transmission method, device, terminal device and storage medium
US10243820B2 (en) 2016-09-28 2019-03-26 Amazon Technologies, Inc. Filtering network health information based on customer impact
US10250446B2 (en) 2017-03-27 2019-04-02 Cisco Technology, Inc. Distributed policy store
US10289438B2 (en) 2016-06-16 2019-05-14 Cisco Technology, Inc. Techniques for coordination of application components deployed on distributed virtual machines
CN109992391A (en) * 2017-12-29 2019-07-09 浙江宇视科技有限公司 Connection management method and system
US10374904B2 (en) 2015-05-15 2019-08-06 Cisco Technology, Inc. Diagnostic network visualization
US10523512B2 (en) 2017-03-24 2019-12-31 Cisco Technology, Inc. Network agent for generating platform specific network policies
US10523541B2 (en) 2017-10-25 2019-12-31 Cisco Technology, Inc. Federated network and application data analytics platform
US10554501B2 (en) 2017-10-23 2020-02-04 Cisco Technology, Inc. Network migration assistant
US10574575B2 (en) 2018-01-25 2020-02-25 Cisco Technology, Inc. Network flow stitching using middle box flow stitching
US10594560B2 (en) 2017-03-27 2020-03-17 Cisco Technology, Inc. Intent driven network policy platform
US10594542B2 (en) 2017-10-27 2020-03-17 Cisco Technology, Inc. System and method for network root cause analysis
US10680887B2 (en) 2017-07-21 2020-06-09 Cisco Technology, Inc. Remote device status audit and recovery
US10708183B2 (en) 2016-07-21 2020-07-07 Cisco Technology, Inc. System and method of providing segment routing as a service
US10708152B2 (en) 2017-03-23 2020-07-07 Cisco Technology, Inc. Predicting application and network performance
US10764141B2 (en) 2017-03-27 2020-09-01 Cisco Technology, Inc. Network agent for reporting to a network policy system
US10798015B2 (en) 2018-01-25 2020-10-06 Cisco Technology, Inc. Discovery of middleboxes using traffic flow stitching
US10826803B2 (en) 2018-01-25 2020-11-03 Cisco Technology, Inc. Mechanism for facilitating efficient policy updates
US10862777B2 (en) 2016-09-28 2020-12-08 Amazon Technologies, Inc. Visualization of network health information
US10873593B2 (en) 2018-01-25 2020-12-22 Cisco Technology, Inc. Mechanism for identifying differences between network snapshots
US10873794B2 (en) 2017-03-28 2020-12-22 Cisco Technology, Inc. Flowlet resolution for application performance monitoring and management
US10911263B2 (en) 2016-09-28 2021-02-02 Amazon Technologies, Inc. Programmatic interfaces for network health information
US10917438B2 (en) 2018-01-25 2021-02-09 Cisco Technology, Inc. Secure publishing for policy updates
US10931629B2 (en) 2016-05-27 2021-02-23 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10972388B2 (en) 2016-11-22 2021-04-06 Cisco Technology, Inc. Federated microburst detection
US10999149B2 (en) 2018-01-25 2021-05-04 Cisco Technology, Inc. Automatic configuration discovery based on traffic flow data
US11128700B2 (en) 2018-01-26 2021-09-21 Cisco Technology, Inc. Load balancing configuration based on traffic flow telemetry
US11233821B2 (en) 2018-01-04 2022-01-25 Cisco Technology, Inc. Network intrusion counter-intelligence
US11641319B2 (en) 2016-09-28 2023-05-02 Amazon Technologies, Inc. Network health data aggregation service
US11765046B1 (en) 2018-01-11 2023-09-19 Cisco Technology, Inc. Endpoint cluster assignment and query generation

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7684422B1 (en) * 2002-01-17 2010-03-23 Juniper Networks, Inc. Systems and methods for congestion control using random early drop at head of buffer
US7382793B1 (en) 2002-01-17 2008-06-03 Juniper Networks, Inc. Systems and methods for determining the bandwidth used by a queue
US7558197B1 (en) 2002-01-17 2009-07-07 Juniper Networks, Inc. Dequeuing and congestion control systems and methods
GB2395856A (en) * 2002-11-26 2004-06-02 King S College London Method for reducing packet congestion at a network node
US20040249917A1 (en) * 2003-06-05 2004-12-09 Cheng Yung Lin Data flow management method
KR100656509B1 (en) * 2004-03-03 2006-12-11 삼성전자주식회사 Congestion avoidance method for video service bandwidth
US7839844B2 (en) * 2004-07-30 2010-11-23 Sony Corporation System and method for dynamically determining retransmit buffer time
US7643503B2 (en) * 2004-07-30 2010-01-05 Sony Corporation System and method for dynamically determining retransmit buffer time
JP2006101004A (en) * 2004-09-28 2006-04-13 Fujitsu Ltd Transmission apparatus and leaky packet band control method
JP4705115B2 (en) * 2005-02-07 2011-06-22 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー Network monitoring
DE102006035098A1 (en) * 2006-07-28 2008-01-31 Siemens Ag Method for transmitting a data packet and network nodes
EP2067295A1 (en) * 2006-10-06 2009-06-10 Telefonaktiebolaget LM Ericsson (PUBL) Signal quality indicator
JP2009199453A (en) * 2008-02-22 2009-09-03 Hitachi Ltd Method for deciding whether client is appropriate or not, and storage controller
US8144611B2 (en) * 2009-02-10 2012-03-27 Microsoft Corporation Network coordinate systems using IP information
KR101568288B1 (en) * 2009-09-21 2015-11-12 삼성전자주식회사 Apparatus and method for receiving peer-to-peer data
US20110282980A1 (en) * 2010-05-11 2011-11-17 Udaya Kumar Dynamic protection of a resource during sudden surges in traffic
EP2437440A1 (en) 2010-10-01 2012-04-04 Koninklijke Philips Electronics N.V. Device and method for delay optimization of end-to-end data packet transmissions in wireless networks
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
TWI459768B (en) * 2011-12-30 2014-11-01 Ind Tech Res Inst Communication system and method for assisting transmission of tcp packets
EP2979407B1 (en) 2013-03-28 2018-09-12 British Telecommunications public limited company Re-marking of packets for queue control
GB201313760D0 (en) * 2013-07-31 2013-09-18 British Telecomm Fast friendly start for a data flow
US20160139924A1 (en) * 2014-11-14 2016-05-19 Intel Corporation Machine Level Instructions to Compute a 4D Z-Curve Index from 4D Coordinates
US10645016B2 (en) 2015-08-06 2020-05-05 British Telecommunications Public Limited Company Data packet network
WO2017021048A1 (en) * 2015-08-06 2017-02-09 British Telecommunications Public Limited Company Data packet network
EP3185493A1 (en) * 2015-12-24 2017-06-28 Alcatel Lucent Data packet transport layer with utility based fairness

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5224099A (en) 1991-05-17 1993-06-29 Stratacom, Inc. Circuitry and method for fair queuing and servicing cell traffic using hopcounts and traffic classes
US6760309B1 (en) * 2000-03-28 2004-07-06 3Com Corporation Method of dynamic prioritization of time sensitive packets over a packet based network

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5224009A (en) * 1990-01-16 1993-06-29 Hubbell Incorporated Shallow electrical receptacle with surge suppression and isolated ground

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5224099A (en) 1991-05-17 1993-06-29 Stratacom, Inc. Circuitry and method for fair queuing and servicing cell traffic using hopcounts and traffic classes
US6760309B1 (en) * 2000-03-28 2004-07-06 3Com Corporation Method of dynamic prioritization of time sensitive packets over a packet based network

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
B. Suter, T.V. Lakshman, D. Stiliadis, A. Choudhury, "Efficient Active Queue Management for Internet Routers", Proc. INTEROP 1998 Engineering Conference, pp. 1-21.
D. Lin and R. Morris, "Dynamics of Random Early Detection", SIGCOM 1997.
F. M. Anjum and L. Tassiulas, "Balanced-RED: An Algorithm to Achieve Fairness in the Internet", Technical Research Report, Mar. 8, 1999.
F. M. Anjum and L. Tassiulas, "Fair Bandwidth Sharing Among Adaptive and Non-Adaptive Flows in the Internet", Proceedings of IEEE INFCOM 1999, 9 pages
L.L. Peterson & B.S. Davie, "Computer Networks: A Systems Approach", Morgan Kaufmann publishers, 2000, 2 pages.
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", Request for Comments 2475, Dec. 1998, pp. 1-32.
S. Floyd and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, vol. 1, No. 4, Aug. 1993, 397-413.
W.R. Stevens, "TCP/IP Illustrated, vol. 1", Addison-Wesley, 1997, 3 pages.

Cited By (159)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7881190B2 (en) * 2001-09-12 2011-02-01 Alcatel Method and apparatus for differentiating service in a data network
US20030048791A1 (en) * 2001-09-12 2003-03-13 Alcatel Method and apparatus for differentiating service in a data network
US20060227706A1 (en) * 2002-03-01 2006-10-12 Bellsouth Intellectual Property Corp. System and method for delay-based congestion detection and connection admission control
US7558265B2 (en) * 2003-01-31 2009-07-07 Intel Corporation Methods and apparatus to limit transmission of data to a localized area
US8937943B2 (en) 2003-01-31 2015-01-20 Intel Corporation Methods and apparatus to limit transmission of data to a localized area
US20040151179A1 (en) * 2003-01-31 2004-08-05 Andre Michael R.. Methods and apparatus to limit transmission of data to a localized area
US20100008364A1 (en) * 2003-01-31 2010-01-14 Andre Michael R Methods and apparatus to limit transmission of data to a localized area
US8094662B2 (en) 2003-01-31 2012-01-10 Intel Corporation Methods and apparatus to limit transmission of data to a localized area
US7636321B1 (en) * 2003-05-12 2009-12-22 Sprint Communications Company L.P. Method and system for measuring round-trip time of packets in a communications network
US20060069804A1 (en) * 2004-08-25 2006-03-30 Ntt Docomo, Inc. Server device, client device, and process execution method
US8001188B2 (en) * 2004-08-25 2011-08-16 Ntt Docomo, Inc. Server device, client device, and process execution method
US7330429B2 (en) * 2004-10-27 2008-02-12 Rockwell Electronic Commerce Technologies, Inc. Method and apparatus for internet protocol transaction routing
US20060088024A1 (en) * 2004-10-27 2006-04-27 Rockwell Electronic Commerce Technologies, Llc Method and apparatus for internet protocol transaction routing
US7855974B2 (en) 2004-12-23 2010-12-21 Solera Networks, Inc. Method and apparatus for network packet capture distributed storage system
US7684347B2 (en) 2004-12-23 2010-03-23 Solera Networks Method and apparatus for network packet capture distributed storage system
US20060218620A1 (en) * 2005-03-03 2006-09-28 Dinesh Nadarajah Network digital video recorder and method
US20070058559A1 (en) * 2005-09-15 2007-03-15 Sharp Laboratories Of America, Inc. Method and system of assigning priority to detection messages
KR101419785B1 (en) * 2006-11-29 2014-07-15 톰슨 라이센싱 Methods and a device for secure distance calculation in communication networks
US8325729B2 (en) * 2006-11-29 2012-12-04 Thomson Licensing Methods and a device for secure distance calculation in communication networks
US20080181126A1 (en) * 2006-11-29 2008-07-31 Alain Durand Methods and a device for secure distance calculation in communication networks
US8249992B2 (en) 2007-03-22 2012-08-21 The Nielsen Company (Us), Llc Digital rights management and audience measurement systems and methods
US20080249961A1 (en) * 2007-03-22 2008-10-09 Harkness David H Digital rights management and audience measurement systems and methods
US20080294647A1 (en) * 2007-05-21 2008-11-27 Arun Ramaswamy Methods and apparatus to monitor content distributed by the internet
US20090097483A1 (en) * 2007-10-15 2009-04-16 Canon Kabushiki Kaisha Method and device for transmitting data
US8462778B2 (en) * 2007-10-15 2013-06-11 Canon Kabushiki Kaisha Method and device for transmitting data
US8521732B2 (en) 2008-05-23 2013-08-27 Solera Networks, Inc. Presentation of an extracted artifact based on an indexing technique
US8625642B2 (en) 2008-05-23 2014-01-07 Solera Networks, Inc. Method and apparatus of network artifact indentification and extraction
US20100046927A1 (en) * 2008-08-20 2010-02-25 At&T Intellectual Property I, L.P. System and Method for Retrieving a Previously Transmitted Portion of Television Program Content
US11102554B2 (en) 2008-08-20 2021-08-24 At&T Intellectual Property I, L.P. System and method for retrieving a previously transmitted portion of television program content
US9838750B2 (en) 2008-08-20 2017-12-05 At&T Intellectual Property I, L.P. System and method for retrieving a previously transmitted portion of television program content
US9083635B1 (en) * 2010-10-04 2015-07-14 Adtran, Inc. Enqueue policing systems and methods
US8849991B2 (en) 2010-12-15 2014-09-30 Blue Coat Systems, Inc. System and method for hypertext transfer protocol layered reconstruction
US8666985B2 (en) 2011-03-16 2014-03-04 Solera Networks, Inc. Hardware accelerated application-based pattern matching for real time classification and recording of network traffic
US10177977B1 (en) 2013-02-13 2019-01-08 Cisco Technology, Inc. Deployment and upgrade of network devices in a network environment
US10374904B2 (en) 2015-05-15 2019-08-06 Cisco Technology, Inc. Diagnostic network visualization
US10116559B2 (en) 2015-05-27 2018-10-30 Cisco Technology, Inc. Operations, administration and management (OAM) in overlay data center environments
US10623283B2 (en) 2015-06-05 2020-04-14 Cisco Technology, Inc. Anomaly detection through header field entropy
US11405291B2 (en) 2015-06-05 2022-08-02 Cisco Technology, Inc. Generate a communication graph using an application dependency mapping (ADM) pipeline
US12113684B2 (en) 2015-06-05 2024-10-08 Cisco Technology, Inc. Identifying bogon address spaces
US10089099B2 (en) 2015-06-05 2018-10-02 Cisco Technology, Inc. Automatic software upgrade
US10116531B2 (en) 2015-06-05 2018-10-30 Cisco Technology, Inc Round trip time (RTT) measurement based upon sequence number
US10033766B2 (en) 2015-06-05 2018-07-24 Cisco Technology, Inc. Policy-driven compliance
US10116530B2 (en) 2015-06-05 2018-10-30 Cisco Technology, Inc. Technologies for determining sensor deployment characteristics
US10129117B2 (en) 2015-06-05 2018-11-13 Cisco Technology, Inc. Conditional policies
US11968103B2 (en) 2015-06-05 2024-04-23 Cisco Technology, Inc. Policy utilization analysis
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US11968102B2 (en) 2015-06-05 2024-04-23 Cisco Technology, Inc. System and method of detecting packet loss in a distributed sensor-collector architecture
US10171319B2 (en) 2015-06-05 2019-01-01 Cisco Technology, Inc. Technologies for annotating process and user information for network flows
US10009240B2 (en) 2015-06-05 2018-06-26 Cisco Technology, Inc. System and method of recommending policies that result in particular reputation scores for hosts
US10177998B2 (en) 2015-06-05 2019-01-08 Cisco Technology, Inc. Augmenting flow data for improved network monitoring and management
US10181987B2 (en) 2015-06-05 2019-01-15 Cisco Technology, Inc. High availability of collectors of traffic reported by network sensors
US10230597B2 (en) 2015-06-05 2019-03-12 Cisco Technology, Inc. Optimizations for application dependency mapping
US11936663B2 (en) 2015-06-05 2024-03-19 Cisco Technology, Inc. System for monitoring and managing datacenters
US10243817B2 (en) 2015-06-05 2019-03-26 Cisco Technology, Inc. System and method of assigning reputation scores to hosts
US11924073B2 (en) 2015-06-05 2024-03-05 Cisco Technology, Inc. System and method of assigning reputation scores to hosts
US11924072B2 (en) 2015-06-05 2024-03-05 Cisco Technology, Inc. Technologies for annotating process and user information for network flows
US11902122B2 (en) 2015-06-05 2024-02-13 Cisco Technology, Inc. Application monitoring prioritization
US10305757B2 (en) 2015-06-05 2019-05-28 Cisco Technology, Inc. Determining a reputation of a network entity
US10320630B2 (en) 2015-06-05 2019-06-11 Cisco Technology, Inc. Hierarchichal sharding of flows from sensors to collectors
US10326673B2 (en) 2015-06-05 2019-06-18 Cisco Technology, Inc. Techniques for determining network topologies
US10326672B2 (en) 2015-06-05 2019-06-18 Cisco Technology, Inc. MDL-based clustering for application dependency mapping
US11902120B2 (en) 2015-06-05 2024-02-13 Cisco Technology, Inc. Synthetic data for determining health of a network security system
US9979615B2 (en) 2015-06-05 2018-05-22 Cisco Technology, Inc. Techniques for determining network topologies
US10439904B2 (en) 2015-06-05 2019-10-08 Cisco Technology, Inc. System and method of determining malicious processes
US10454793B2 (en) 2015-06-05 2019-10-22 Cisco Technology, Inc. System and method of detecting whether a source of a packet flow transmits packets which bypass an operating system stack
US11902121B2 (en) 2015-06-05 2024-02-13 Cisco Technology, Inc. System and method of detecting whether a source of a packet flow transmits packets which bypass an operating system stack
US10505827B2 (en) 2015-06-05 2019-12-10 Cisco Technology, Inc. Creating classifiers for servers and clients in a network
US10505828B2 (en) 2015-06-05 2019-12-10 Cisco Technology, Inc. Technologies for managing compromised sensors in virtualized environments
US10516586B2 (en) 2015-06-05 2019-12-24 Cisco Technology, Inc. Identifying bogon address spaces
US10516585B2 (en) 2015-06-05 2019-12-24 Cisco Technology, Inc. System and method for network information mapping and displaying
US11894996B2 (en) 2015-06-05 2024-02-06 Cisco Technology, Inc. Technologies for annotating process and user information for network flows
US11700190B2 (en) 2015-06-05 2023-07-11 Cisco Technology, Inc. Technologies for annotating process and user information for network flows
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US11695659B2 (en) 2015-06-05 2023-07-04 Cisco Technology, Inc. Unique ID generation for sensors
US10567247B2 (en) 2015-06-05 2020-02-18 Cisco Technology, Inc. Intra-datacenter attack detection
US11637762B2 (en) 2015-06-05 2023-04-25 Cisco Technology, Inc. MDL-based clustering for dependency mapping
US11601349B2 (en) 2015-06-05 2023-03-07 Cisco Technology, Inc. System and method of detecting hidden processes by analyzing packet flows
US11528283B2 (en) 2015-06-05 2022-12-13 Cisco Technology, Inc. System for monitoring and managing datacenters
US10623282B2 (en) 2015-06-05 2020-04-14 Cisco Technology, Inc. System and method of detecting hidden processes by analyzing packet flows
US9967158B2 (en) 2015-06-05 2018-05-08 Cisco Technology, Inc. Interactive hierarchical network chord diagram for application dependency mapping
US10623284B2 (en) 2015-06-05 2020-04-14 Cisco Technology, Inc. Determining a reputation of a network entity
US10659324B2 (en) 2015-06-05 2020-05-19 Cisco Technology, Inc. Application monitoring prioritization
US11522775B2 (en) 2015-06-05 2022-12-06 Cisco Technology, Inc. Application monitoring prioritization
US10686804B2 (en) 2015-06-05 2020-06-16 Cisco Technology, Inc. System for monitoring and managing datacenters
US10693749B2 (en) 2015-06-05 2020-06-23 Cisco Technology, Inc. Synthetic data for determining health of a network security system
US11516098B2 (en) 2015-06-05 2022-11-29 Cisco Technology, Inc. Round trip time (RTT) measurement based upon sequence number
US11502922B2 (en) 2015-06-05 2022-11-15 Cisco Technology, Inc. Technologies for managing compromised sensors in virtualized environments
US10728119B2 (en) 2015-06-05 2020-07-28 Cisco Technology, Inc. Cluster discovery via multi-domain fusion for application dependency mapping
US10735283B2 (en) 2015-06-05 2020-08-04 Cisco Technology, Inc. Unique ID generation for sensors
US10742529B2 (en) 2015-06-05 2020-08-11 Cisco Technology, Inc. Hierarchichal sharding of flows from sensors to collectors
US11496377B2 (en) 2015-06-05 2022-11-08 Cisco Technology, Inc. Anomaly detection through header field entropy
US10797970B2 (en) 2015-06-05 2020-10-06 Cisco Technology, Inc. Interactive hierarchical network chord diagram for application dependency mapping
US11477097B2 (en) 2015-06-05 2022-10-18 Cisco Technology, Inc. Hierarchichal sharding of flows from sensors to collectors
US10797973B2 (en) 2015-06-05 2020-10-06 Cisco Technology, Inc. Server-client determination
US11431592B2 (en) 2015-06-05 2022-08-30 Cisco Technology, Inc. System and method of detecting whether a source of a packet flow transmits packets which bypass an operating system stack
US10862776B2 (en) 2015-06-05 2020-12-08 Cisco Technology, Inc. System and method of spoof detection
US11368378B2 (en) 2015-06-05 2022-06-21 Cisco Technology, Inc. Identifying bogon address spaces
US11252058B2 (en) 2015-06-05 2022-02-15 Cisco Technology, Inc. System and method for user optimized application dependency mapping
US11252060B2 (en) 2015-06-05 2022-02-15 Cisco Technology, Inc. Data center traffic analytics synchronization
US11153184B2 (en) 2015-06-05 2021-10-19 Cisco Technology, Inc. Technologies for annotating process and user information for network flows
US10904116B2 (en) 2015-06-05 2021-01-26 Cisco Technology, Inc. Policy utilization analysis
US11128552B2 (en) 2015-06-05 2021-09-21 Cisco Technology, Inc. Round trip time (RTT) measurement based upon sequence number
US11121948B2 (en) 2015-06-05 2021-09-14 Cisco Technology, Inc. Auto update of sensor configuration
US9935851B2 (en) 2015-06-05 2018-04-03 Cisco Technology, Inc. Technologies for determining sensor placement and topology
US10917319B2 (en) 2015-06-05 2021-02-09 Cisco Technology, Inc. MDL-based clustering for dependency mapping
US11102093B2 (en) 2015-06-05 2021-08-24 Cisco Technology, Inc. System and method of assigning reputation scores to hosts
US10979322B2 (en) 2015-06-05 2021-04-13 Cisco Technology, Inc. Techniques for determining network anomalies in data center networks
US10044581B1 (en) 2015-09-29 2018-08-07 Amazon Technologies, Inc. Network traffic tracking using encapsulation protocol
US10033602B1 (en) 2015-09-29 2018-07-24 Amazon Technologies, Inc. Network health management using metrics from encapsulation protocol endpoints
US10917322B2 (en) 2015-09-29 2021-02-09 Amazon Technologies, Inc. Network traffic tracking using encapsulation protocol
US10171357B2 (en) 2016-05-27 2019-01-01 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US11546288B2 (en) 2016-05-27 2023-01-03 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US12021826B2 (en) 2016-05-27 2024-06-25 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10931629B2 (en) 2016-05-27 2021-02-23 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10289438B2 (en) 2016-06-16 2019-05-14 Cisco Technology, Inc. Techniques for coordination of application components deployed on distributed virtual machines
US11283712B2 (en) 2016-07-21 2022-03-22 Cisco Technology, Inc. System and method of providing segment routing as a service
US10708183B2 (en) 2016-07-21 2020-07-07 Cisco Technology, Inc. System and method of providing segment routing as a service
US10911263B2 (en) 2016-09-28 2021-02-02 Amazon Technologies, Inc. Programmatic interfaces for network health information
US12068938B2 (en) 2016-09-28 2024-08-20 Amazon Technologies, Inc. Network health data aggregation service
US11641319B2 (en) 2016-09-28 2023-05-02 Amazon Technologies, Inc. Network health data aggregation service
US10243820B2 (en) 2016-09-28 2019-03-26 Amazon Technologies, Inc. Filtering network health information based on customer impact
US10862777B2 (en) 2016-09-28 2020-12-08 Amazon Technologies, Inc. Visualization of network health information
US10972388B2 (en) 2016-11-22 2021-04-06 Cisco Technology, Inc. Federated microburst detection
US10708152B2 (en) 2017-03-23 2020-07-07 Cisco Technology, Inc. Predicting application and network performance
US11088929B2 (en) 2017-03-23 2021-08-10 Cisco Technology, Inc. Predicting application and network performance
US11252038B2 (en) 2017-03-24 2022-02-15 Cisco Technology, Inc. Network agent for generating platform specific network policies
US10523512B2 (en) 2017-03-24 2019-12-31 Cisco Technology, Inc. Network agent for generating platform specific network policies
US10594560B2 (en) 2017-03-27 2020-03-17 Cisco Technology, Inc. Intent driven network policy platform
US11509535B2 (en) 2017-03-27 2022-11-22 Cisco Technology, Inc. Network agent for reporting to a network policy system
US11146454B2 (en) 2017-03-27 2021-10-12 Cisco Technology, Inc. Intent driven network policy platform
US10764141B2 (en) 2017-03-27 2020-09-01 Cisco Technology, Inc. Network agent for reporting to a network policy system
US10250446B2 (en) 2017-03-27 2019-04-02 Cisco Technology, Inc. Distributed policy store
US11863921B2 (en) 2017-03-28 2024-01-02 Cisco Technology, Inc. Application performance monitoring and management platform with anomalous flowlet resolution
US10873794B2 (en) 2017-03-28 2020-12-22 Cisco Technology, Inc. Flowlet resolution for application performance monitoring and management
US11202132B2 (en) 2017-03-28 2021-12-14 Cisco Technology, Inc. Application performance monitoring and management platform with anomalous flowlet resolution
US11683618B2 (en) 2017-03-28 2023-06-20 Cisco Technology, Inc. Application performance monitoring and management platform with anomalous flowlet resolution
US10466934B2 (en) * 2017-05-12 2019-11-05 Guavus, Inc. Methods and systems for time-based binning of network traffic
US20180331922A1 (en) * 2017-05-12 2018-11-15 Pragati Kumar Dhingra Methods and systems for time-based binning of network traffic
US10680887B2 (en) 2017-07-21 2020-06-09 Cisco Technology, Inc. Remote device status audit and recovery
US11044170B2 (en) 2017-10-23 2021-06-22 Cisco Technology, Inc. Network migration assistant
US10554501B2 (en) 2017-10-23 2020-02-04 Cisco Technology, Inc. Network migration assistant
US10523541B2 (en) 2017-10-25 2019-12-31 Cisco Technology, Inc. Federated network and application data analytics platform
US10904071B2 (en) 2017-10-27 2021-01-26 Cisco Technology, Inc. System and method for network root cause analysis
US10594542B2 (en) 2017-10-27 2020-03-17 Cisco Technology, Inc. System and method for network root cause analysis
CN109992391B (en) * 2017-12-29 2021-09-28 浙江宇视科技有限公司 Connection management method and system
CN109992391A (en) * 2017-12-29 2019-07-09 浙江宇视科技有限公司 Connection management method and system
US11233821B2 (en) 2018-01-04 2022-01-25 Cisco Technology, Inc. Network intrusion counter-intelligence
US11750653B2 (en) 2018-01-04 2023-09-05 Cisco Technology, Inc. Network intrusion counter-intelligence
US11765046B1 (en) 2018-01-11 2023-09-19 Cisco Technology, Inc. Endpoint cluster assignment and query generation
US10798015B2 (en) 2018-01-25 2020-10-06 Cisco Technology, Inc. Discovery of middleboxes using traffic flow stitching
US10574575B2 (en) 2018-01-25 2020-02-25 Cisco Technology, Inc. Network flow stitching using middle box flow stitching
US11924240B2 (en) 2018-01-25 2024-03-05 Cisco Technology, Inc. Mechanism for identifying differences between network snapshots
US10917438B2 (en) 2018-01-25 2021-02-09 Cisco Technology, Inc. Secure publishing for policy updates
US10873593B2 (en) 2018-01-25 2020-12-22 Cisco Technology, Inc. Mechanism for identifying differences between network snapshots
US10826803B2 (en) 2018-01-25 2020-11-03 Cisco Technology, Inc. Mechanism for facilitating efficient policy updates
US10999149B2 (en) 2018-01-25 2021-05-04 Cisco Technology, Inc. Automatic configuration discovery based on traffic flow data
US11128700B2 (en) 2018-01-26 2021-09-21 Cisco Technology, Inc. Load balancing configuration based on traffic flow telemetry
CN109474538A (en) * 2018-12-29 2019-03-15 北京达佳互联信息技术有限公司 A kind of data transmission method, device, terminal device and storage medium
CN109474538B (en) * 2018-12-29 2021-07-30 北京达佳互联信息技术有限公司 Data transmission method and device, terminal equipment and storage medium

Also Published As

Publication number Publication date
US20030007454A1 (en) 2003-01-09

Similar Documents

Publication Publication Date Title
US6958998B2 (en) Traffic management in packet-based networks
Suter et al. Design considerations for supporting TCP with per-flow queueing
US7385986B2 (en) Packet transfer method and apparatus
US7983159B2 (en) Queue-based active queue management process
US6839321B1 (en) Domain based congestion management
US8724462B2 (en) Congestion handling in a packet switched network domain
CN101552726B (en) A grading services edge router
JP2005295581A (en) Method for improving performance of tcp connection
Chatranon et al. A survey of TCP-friendly router-based AQM schemes
JP2002111742A (en) Method for marking packet of data transmission flow and marker device performing this method
Albuquerque et al. Network border patrol: Preventing congestion collapse and promoting fairness in the internet
US8289851B2 (en) Lightweight bandwidth-management scheme for elastic traffic
Sisalem et al. The direct adjustment algorithm: A TCP-friendly adaptation scheme
Wen et al. Differentiated bandwidth allocation with TCP protection in core routers
Császár et al. Severe congestion handling with resource management in diffserv on demand
Agarwal et al. Link utilization based AQM and its performance
Chatranon et al. Fairness of AQM schemes for TCP-friendly traffic
Kawahara et al. Dynamically weighted queueing for fair bandwidth allocation and its performance analysis
Liu Simulation and evaluation of random early detection in congestion control
Siew et al. Congestion control based on flow-state-dependent dynamic priority scheduling
Yang Pushout with Differentiated Dropping Queue Management for High-Speed Networks
Wang et al. C3P: a cooperant congestion control protocol in high bandwidth-delay product networks
Grochla Simulation comparison of active queue management algorithms in TCP/IP networks
Pan et al. CHOKe-A simple approach for providing Quality of Service through stateless approximation of fair queueing
Lin et al. Scalable fair random early detection

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHOREY, RAJEEV;REEL/FRAME:012650/0625

Effective date: 20010619

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20131025