CA2372023A1 - Overload control method for a packet-switched network - Google Patents
Overload control method for a packet-switched network Download PDFInfo
- Publication number
- CA2372023A1 CA2372023A1 CA002372023A CA2372023A CA2372023A1 CA 2372023 A1 CA2372023 A1 CA 2372023A1 CA 002372023 A CA002372023 A CA 002372023A CA 2372023 A CA2372023 A CA 2372023A CA 2372023 A1 CA2372023 A1 CA 2372023A1
- Authority
- CA
- Canada
- Prior art keywords
- congestion
- packet
- data packet
- congestion notification
- network
- 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.)
- Abandoned
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/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
-
- 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/35—Flow control; Congestion control by embedding flow control information in regular packets, e.g. piggybacking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Abstract
The invention relates to a method for controlling overload in a packet- switched network, especially a mobile or wireless network where the transmission control protocol (TCP) is used as the transport layer protocol. A congestion notification information is added to a data packet following a da ta packet lost due to a buffer overflow. This is an effective way to improve TC P performance in wireless and mobile networks, since congestion control can be performed completely independent from retransmissions. The proposed mechanis m provides a simple way of introducing TCP congestion avoidance control strategies into wireless and mobile networks. In addition, the congestion notification information should be added at least not later than a threshold number of following packets to thereby fasten the rate of congestion control initiation and loss recovery due to congestion.
Description
Overload control method for a packet-switched network FIELD OF THE INVENTION
The present invention relates to a method for controlling overload in a packed-switched network, especially a wireless or mobile network in which the Transmission Control Protocol (TCP) is used as a transport layer protocol.
BACKGROUND OF THE INVENTION
Overload or congestion control is one of the key mechanisms to accommodate the increasingly diverse range of services and types of traffic in the Internet. As commonly known, TCP is the most popular transport layer protocol for data transfer. It provides connection-oriented reliable transfer of data between two connecting hosts, wherein a host refers to a network-connected computer or to any system which can be connected to a network for offering services to another host connected to the same network. TCP uses several techniques to maximize the performance of the connection by monitoring different variables relating to the connection.
For example, TCP includes an internal algorithm for avoiding congestion.
Congestion control relates to the general problem of traffic management for packet-switched networks. Congestion means a situation in which the number of transmission requests at a specific time exceeds the transmission capacity at a certain network point (called a bottle-neck resource). Congestion usually results in overload conditions. As a result, the buffers may overflow, for instance, so that packets are retransmitted either by the network or by the subscriber. In general, congestion arises, when the incoming traffic to a specific link is more than the outgoing link capacity. The primary function of congestion control is to ensure good throughput and delay performance while maintaining a fair allocation of network resources to the users. For the TCP traffic, whose traffic patterns are often highly bursty, connection control poses a challenging problem. It is known that packet losses result in a significant degradation in TCP
throughput. Thus, for the best possible throughput, a minimum number of packet losses should occur.
Currently, several schemes, including Fast-TCP, have been put forward to enhance the function of avoiding congestion in the TCP flow control. Although the purpose of these mechanisms is to avoid packet droppings in case of queue overflows, network congestion cannot be completely avoided even with very perfect congestion avoidance mechanisms.
Thus, it is still necessary to combine these mechanisms with existing TCP flow control mechanisms for congestion control, that is, source window reduction shall sometimes be invoked by lost packets due to a buffer overflow, to thereby alleviate the congestion in time.
Initially, the Internet was intended to support best-effort service, and the TCP congestion control method that was actually implemented has been developed on the assumption that the network would be treated as a black box. This means that the end nodes do not exercise control by directly ascertaining the state of routers and transmission lines, but rather regulate the traffic by inferring the network load indirectly from packet loss and response time fluctuations. In wired networks, this may not induce serious problems, as packet losses mainly occur due to congestion. However, in the presence of high error rates and intermittent connective characteristic as in wireless links, this reliance on packet drops as an indicator of congestion causes a significant degradation in TCP
performance, since the TCP reacts to packet losses as it would in the wired environment. Namely, it drops its retransmit window size before retransmitting packets, initiates congestion control or avoidance mechanisms and resets its retransmission timer. This results in an unnecessary reduction in the link bandwidth utilization of wireless and mobile networks, causing poor throughput and very high interactive delays.
Recently, several schemes have been proposed to alleviate the effects of non-congestion-related losses on TCP
performance over networks that have wireless or similar high-loss links.
In the article "Implementation and Performance Evaluation of Indirect TCP" by Ajay V. Bakre et al, IEEE Transactions on computers, Vol. 46, No. 3, March 1997, the Indirect-TCP
protocol is described as one of the first protocols to distinguish different losses by splitting a TCP connection between a fixed and a mobile host into two separate connections at the base station, such that a more optimized wireless link-specific protocol tuned for better performance can be used over a one-hop wireless link.
However, there are some drawbacks of this approach, such as loss of semantics, application re-linking and software overhead.
Furthermore, an ELN (Explicit Loss Notification) protocol has been proposed, wherein an explicit loss notification option is added to TCP acknowledgments, when a packet is dropped on the wireless link. In this case, future cumulative acknowledgments corresponding to each lost packet must always be marked to identify that a non-congestion-related loss has occurred. Moreover, it might be difficult to identify packets lost due to errors on lossy links and to determine a connection of a corrupted packet, since the header could itself be corrupted.
Additionally, another research area is described in "A
proposal to add Explicit Congestion Notification (ECN) to IP" by K.K. Ramakrishnan et al, Internet Draft-kksjf-ecn-02.txt, September 1998, wherein congestion control is decoupled from packet loss. By doing this, packet losses will not invoke congestion control, such that transmission errors do not lead to a reduced throughput. In particular, an Explicit Congestion Notification (ECN) is added to a TCP
acknowledgment option by detecting incipient congestion in the network. Upon receiving this ECN message, the transmitter reduces its congestion window whenever a loss occurs.
However, many current networks with routers whose main function is to route packets have no provision for the detection of an incipient congestion before a queue overflow occurs. Nevertheless, even if such a provision were provided, the packet marking rate could not catch up with its passing rate during periods where the average queue size exceeds an upper threshold. Therefore, routers drop packets rather than setting the ECN in the packet header.
In spite of all these difficulties, ECN is likely to be adopted gradually. Thus, accommodating migration is an essential requirement for future TCP networks.
The present invention relates to a method for controlling overload in a packed-switched network, especially a wireless or mobile network in which the Transmission Control Protocol (TCP) is used as a transport layer protocol.
BACKGROUND OF THE INVENTION
Overload or congestion control is one of the key mechanisms to accommodate the increasingly diverse range of services and types of traffic in the Internet. As commonly known, TCP is the most popular transport layer protocol for data transfer. It provides connection-oriented reliable transfer of data between two connecting hosts, wherein a host refers to a network-connected computer or to any system which can be connected to a network for offering services to another host connected to the same network. TCP uses several techniques to maximize the performance of the connection by monitoring different variables relating to the connection.
For example, TCP includes an internal algorithm for avoiding congestion.
Congestion control relates to the general problem of traffic management for packet-switched networks. Congestion means a situation in which the number of transmission requests at a specific time exceeds the transmission capacity at a certain network point (called a bottle-neck resource). Congestion usually results in overload conditions. As a result, the buffers may overflow, for instance, so that packets are retransmitted either by the network or by the subscriber. In general, congestion arises, when the incoming traffic to a specific link is more than the outgoing link capacity. The primary function of congestion control is to ensure good throughput and delay performance while maintaining a fair allocation of network resources to the users. For the TCP traffic, whose traffic patterns are often highly bursty, connection control poses a challenging problem. It is known that packet losses result in a significant degradation in TCP
throughput. Thus, for the best possible throughput, a minimum number of packet losses should occur.
Currently, several schemes, including Fast-TCP, have been put forward to enhance the function of avoiding congestion in the TCP flow control. Although the purpose of these mechanisms is to avoid packet droppings in case of queue overflows, network congestion cannot be completely avoided even with very perfect congestion avoidance mechanisms.
Thus, it is still necessary to combine these mechanisms with existing TCP flow control mechanisms for congestion control, that is, source window reduction shall sometimes be invoked by lost packets due to a buffer overflow, to thereby alleviate the congestion in time.
Initially, the Internet was intended to support best-effort service, and the TCP congestion control method that was actually implemented has been developed on the assumption that the network would be treated as a black box. This means that the end nodes do not exercise control by directly ascertaining the state of routers and transmission lines, but rather regulate the traffic by inferring the network load indirectly from packet loss and response time fluctuations. In wired networks, this may not induce serious problems, as packet losses mainly occur due to congestion. However, in the presence of high error rates and intermittent connective characteristic as in wireless links, this reliance on packet drops as an indicator of congestion causes a significant degradation in TCP
performance, since the TCP reacts to packet losses as it would in the wired environment. Namely, it drops its retransmit window size before retransmitting packets, initiates congestion control or avoidance mechanisms and resets its retransmission timer. This results in an unnecessary reduction in the link bandwidth utilization of wireless and mobile networks, causing poor throughput and very high interactive delays.
Recently, several schemes have been proposed to alleviate the effects of non-congestion-related losses on TCP
performance over networks that have wireless or similar high-loss links.
In the article "Implementation and Performance Evaluation of Indirect TCP" by Ajay V. Bakre et al, IEEE Transactions on computers, Vol. 46, No. 3, March 1997, the Indirect-TCP
protocol is described as one of the first protocols to distinguish different losses by splitting a TCP connection between a fixed and a mobile host into two separate connections at the base station, such that a more optimized wireless link-specific protocol tuned for better performance can be used over a one-hop wireless link.
However, there are some drawbacks of this approach, such as loss of semantics, application re-linking and software overhead.
Furthermore, an ELN (Explicit Loss Notification) protocol has been proposed, wherein an explicit loss notification option is added to TCP acknowledgments, when a packet is dropped on the wireless link. In this case, future cumulative acknowledgments corresponding to each lost packet must always be marked to identify that a non-congestion-related loss has occurred. Moreover, it might be difficult to identify packets lost due to errors on lossy links and to determine a connection of a corrupted packet, since the header could itself be corrupted.
Additionally, another research area is described in "A
proposal to add Explicit Congestion Notification (ECN) to IP" by K.K. Ramakrishnan et al, Internet Draft-kksjf-ecn-02.txt, September 1998, wherein congestion control is decoupled from packet loss. By doing this, packet losses will not invoke congestion control, such that transmission errors do not lead to a reduced throughput. In particular, an Explicit Congestion Notification (ECN) is added to a TCP
acknowledgment option by detecting incipient congestion in the network. Upon receiving this ECN message, the transmitter reduces its congestion window whenever a loss occurs.
However, many current networks with routers whose main function is to route packets have no provision for the detection of an incipient congestion before a queue overflow occurs. Nevertheless, even if such a provision were provided, the packet marking rate could not catch up with its passing rate during periods where the average queue size exceeds an upper threshold. Therefore, routers drop packets rather than setting the ECN in the packet header.
In spite of all these difficulties, ECN is likely to be adopted gradually. Thus, accommodating migration is an essential requirement for future TCP networks.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide a method for controlling overload in a packet-switched network, and a packet-switched telecommunication network, by means of which an unnecessary reduction of the link bandwidth utilization can be prevented.
This object is achieved by a method for controlling overload in a packet-switched network comprising traffic sources, traffic destinations and network nodes, said method comprising the steps of:
transmitting data packets from one of said traffic sources to one of said traffic destinations;
transmitting an acknowledgment packet from said one traffic destination to said one traffic source, if a data packet has been received correctly at said one destination; and adding a congestion notification information to a data packet following a data packet lost due to a buffer overflow.
Additionally, the above object is achieved by a packet-switched telecommunication network comprising:
network nodes interconnected by transmission lines;
user terminals connected to said network nodes, said user terminals acting as traffic sources which transmit data packets and as traffic destinations which receive data packets;
detecting means for detecting a loss of a data packet due to a buffer overflow in one of said network nodes; and control means for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detection means.
Accordingly, a short-cut ECN mechanism (Wireless-ECN) which preferably can be used in wireless or mobile environments is provided. Like ELN, the mechanism is arranged to communicate the reason for a packet loss to the TCP source.
In particular, the source can be informed that a loss happened due to reasons related to a network congestion, such that congestion control can be decoupled from retransmissions. Thus, the congestion window is only reduced in case the congestion notification information has been received, without considering packet losses. By quickly informing the source that a loss happened due to reasons relating to a network congestion, congestion control and loss recovery mechanism can be separated. This mechanism is simple to implement and compatible with the existing TCP congestion control.
When Wireless-ECN is used in the traditional ECN
environment, Wireless-ECN is interpreted by the TCP source as a new instance of congestion. The integration of Wireless-ECN into the known ECN mechanism allows congestion control to be initiated by WECN or ECN messages. Since a WECN message should be added at least not later than the threshold number of following packets, it may invoke congestion control even sooner than with the fast retransmission mechanism. The integration of the WECN into the ECN mechanism not only avoids unnecessary congestion-induced packet losses, but also prevents the unnecessary delayed initiation of congestion control which often occurs due to a loss of an ECN packet or an inefficient effect of the ECN mechanism or other exceptions in the ECN mechanism.
Preferably, said following data packet directly follows said lost data packet. This ensures that the congestion notification information can inevitably by added even with multiple packet losses, and there is no need for mechanism in the router to monitor the average queue size. Since the congestion notification information is added as quickly as possible after a packet loss has occurred due to congestion, it is ensured that a network congestion is alleviated in time.
Furthermore, the congestion notification may be added in the header of said following data packet. In this case, bit No. 5 in the IPv 4 TOS octet can be used, for example.
Preferably, each of the network nodes should be able to add the congestion notification information to thereby indicate a congestion-related data loss. Thereby, multiple WECN
messages provide a robustness against the possibility of dropping a WECN packet in the bi-directional transmitting paths.
The congestion notification information is allowed to be added to those following data packets which belong to the same congestion window in the successively past routers.
Moreover, each network node is allowed to add the congestion information only once. Thus each congestion notification information added in a transmission window belongs to another network node.
Having received a data packet with an added congestion notification information, the traffic destination preferably sets a congestion notification flag in the header of an acknowledgment packet. The congestion notification flag may be bit No. 8 in the TCP header of the _ g _ subsequent acknowledgment packet. Since the TCP uses the WECN message to invoke congestion control, only a retransmission mechanism is performed in case of a packet loss without a WECN message. Thus, the TCP data flow rate is not affected. This is very useful in wireless or mobile networks, since the network itself has the function of distinguishing different sources of packet losses. By notifying the source with a WECN acknowledgment packet whenever a congestion-related loss has occurred, packet losses due to transmission errors cannot reduce the TCP
flow control window (congestion window), which results in a significant performance improvement. The congestion window can only be reduced by the congestion notification flag set due to a congestion loss.
Preferably, a congestion processing is repeated at the traffic source only after the outstanding data packets transmitted before the first receipt of a congestion notification flag have all been acknowledged. Thereby, reduction of the congestion window is not repeated, if the packet was dropped before the source reduced its window in response to the congestion notification flag.
The WECN mechanism according to the present invention enables complete decoupling of the congestion control function from packet losses. Compared to ECN, the WECN
notification may inevitably be added, since the dropped packets give the buffer time to vacate some space for holding and transmitting new data. In case a WECN is lost, e.g. in a high loss link condition where all WECN
notifications are lost in a control cycle, or in case only one WECN is added in a transmission window and this WECN is lost by accident, this loss will result in a failure of congestion control for that flow and an increased congestion of the network, since the assumed source of data loss was not a congestion. Nevertheless, other WECNs are added for subsequent dropped packets in the next congestion window. Thus, the mechanism is very secure and robust compared to the ECN mechanism where the loss of an ECN will not cause another addition of an ECN packet.
According to the present invention, no packet losses need to be considered to invoke congestion window reduction.
Since mechanisms for monitoring-the average queue size are not required in the routers, the WECN mechanism can be implemented in a simple manner and opens the way to a further deployment of the ECN mechanism. It is to be noted that the WECN mechanism is compatible with all TCP
congestion control mechanisms, as long as they are invoked by packet losses, and it is easy to incorporate them into wireless and mobile networks. With the incremental deployment of the ECN mechanism, the integration of WECN
into ECN may allow congestion control to be initiated by WECN or ECN messages and WECN packet functions only if a packet lost due to a congestion arrives earlier than an ECN
within the corresponding data window. With the addition of WECN to the Fast-TCP mechanism, the window reduction could be invoked by WECN when a buffer overflow occurs, since the TCP behavior at the end systems is not changed. Thus, this is an effective way of inproving TCP performance in wireless and mobile networks.
In addition, since WECN is required to be added not later than after a threshold number of duplicate acknowledgements, improved TCP performance in wired network environments can be expected, since the initiation of congestion control is accelerated by the WECN message.
Moreover, if this message is used for triggering the transmission or retransmission data packets, it can hasten the speed of entering into the TCP recovery phase due to congestion, such that congestion-induced lost packets are quickly retransmitted.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following, the present invention will be described in greater detail on the basis of a preferred embodiment with reference to the accompanying drawings, in which:
Fig. 1 shows a general block diagram of a flow control loop in a TCP over ATM network, in which the preferred embodiment of the present invention is implemented;
Fig. 2 shows a general block diagram of an intermediate node arranged between a traffic source and a traffic destination, according to the preferred embodiment of the present invention;
Fig. 3 shows a general block diagram of two subsequent intermediate nodes according to the preferred embodiment of the present invention;
Fig. 4 shows a diagram of transmissions between a traffic source and a traffic destination, in case a wireless congestion notification (WECN) arrives at the traffic source before a usual congestion notification (ECN) within the same transmission window;
Fig. 5 shows a diagram of transmissions between the traffic source and the traffic destination, in case a non-congestion packet loss is detected before a congestion notification within the same transmission window;
Fig. 6 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN arrives at the traffic source after an ineffective ECN
implementation in the preceding transmission window;
Fig. 7 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN is received at the traffic source after a normal ECN within the same transmission window;
Fig. 8 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN is set before three following packets in the same transmission window;
Fig. 9 shows a diagram of transmissions between the traffic source and the traffic destination, in case of a WECN and a non-congestion packet loss within the same transmission window; and Fig. 10 shows a diagram of transmissions between the traffic source and the traffic destination, in case of a delayed set of WECN and multiple congestion losses within the same transmission window.
DESCRIPTION OF THE PREFERRED EMBODIMENT
In the following the preferred embodiment of the present invention will be described on the basis of a TCP over ATM
network as shown in Fig. 1.
ATM (Asynchronous Transfer Mode) is a connection-oriented packet-switching technique which the international telecommunication standardization organization ITU-T has chosen as the target solution of the broadband Integrated Services Digital Network (B-ISDN). The problems of conventional packet networks have been eliminated in the ADM network by using short packets of a standard length (53 bytes), known as cells. ATM networks are quickly being adopted as backbones for the various parts of TCP/IP
networks such as the Internet. This also applies to wireless or mobile networks.
According to Fig. 1, a connection between two user terminals A and B in the TCP over ATM network is shown, i.e. the user terminals using TCP as a transport layer protocol. In addition, two access nodes AN1 and AN2 of the user terminals, one intermediate node N1 and transmission lines TL1, TL2 connecting the nodes are shown.
After an initial handshake has been completed, the user terminals A and B begin to transmit data by means of TCP
segments. The term "segment" refers to the unit of information passed by TCP to IP (Internet protocol). IP
headers are attached to these TCP segments to form IP
datagrams, i.e. TCP segments are transferred to the receiver within IP datagrams as the information units used by IP. Each uncorrupted TCP segment including the hand shaking segments, is acknowledged. To illustrate the function of the flow control loop, it is assumed that the user terminal A transmits one TCP segment to the user terminal B. At the network layer, the user terminal A adds an IP header to this TCP segment to form an IP datagram.
This datagram is converted into standard ATM cells in the access node AN1 located at the edge of the ATM network ANW.
The cells of the datagram are then routed through the ATM
network to the access node AN2 of the user terminal B. This access node reconstructs the original IP datagram from the arriving cells and sends the IP datagram to the user terminal B. The user terminal B removes the IP header to reveal the TCP segment. If the segment is received correctly, the user terminal B sends an acknowledging TCP
segment ACK back to the user terminal A.
TCP is one of the few transport protocols that natively has a congestion control mechanism. The preferred embodiment of the present invention relies on this known TCP control mechanism. Therefore, this mechanism is described briefly in the following.
TCP congestion control is based on two variables: the receiver's advertised window (Wrcvr) and the congestion window (CNWD). The receiver's advertised window is maintained at the receiver as a measure of the buffering capacity of the receiver, and the congestion window is maintained at the transmitter as a measure of the capacity of the network. The TCP source can never transmit more segments than the minimum of the receiver's advertised window and the congestion window.
The TCP congestion control method comprises two phases:
slow start and congestion avoidance. A variable called SSTHRES (Slow Start Threshold) is maintained at the source to distinguish between the two phases. The source starts to transmit in the slow start phase by sending one TCP
segment, i.e. the value of CWND is set to one at the beginning. When the source receives an acknowledgment, it increments CWND by one, and, as a consequence, transmits to more segments. In this way the value of CWND doubles every round trip time during the slow start phase, as each segment is acknowledged by the destination terminal. The slow start phase ends and the congestion avoidance phase begins, when CWND reaches the value of SSTHRES.
If a data packet is lost in a TCP connection, the source does not receive an acknowledgment and performs a loss recovery operation.
By duplicating the acknowledgments, the TCP source can be made to slow down its output rate. This is based on the fast retransmission and fast recovery algorithms which the source automatically performs after receiving a certain number of duplicate acknowledgments. These algorithms are widely implemented in different TCP versions. According to the algorithms, the source performs, after having received a predetermined threshold number of acknowledgments (e. g.
three acknowledgements), a retransmission of what appears to be the missing segment, without waiting for the expiry of a retransmission timer (fast retransmission algorithm).
After this, the source performs congestion avoidance, instead of slow start, in order not to reduce the data flow abruptly (fast recovery algorithm).
Fig. 2 shows a general diagram of an intermediate node connected to a TCP source A and a TCP destination B, which both may be workstations or the like. In the intermediate node, a congestion is shown as a black star, a passing data packet as a solid square, and a data packet lost due to the congestion as a doted square.
According to the preferred embodiment of the present invention, a Wireless-ECN (WECN) control means C is provided in the intermediate node, which is arranged to mark a data packet with an explicit wireless congestion notification (WECN) immediately after a packet loss has occurred due to a buffer overflow which may be detected by a detecting means (not shown). The detecting means may be included in the control means C or may be a separate means in the intermediate node.
If a first lost packet due to a buffer overflow in the intermediate node or router is detected within a transmission window of the TCP source A, a WECN is added in the header of the immediately following passing packet. The required time for this operation is available due to the dropped data packet which results in additional buffer time. Thus, the WECN is added as quickly as possible after a packet loss, such that the network congestion can be alleviated as soon as possible.
Furthermore, an arrow at the bottom of Fig. 2 shows the transmitting path of the WECN, wherein the TCP destination B sets a WECN flag in the header of an acknowledgment packet in response to the receipt of a WECN data packet, to thereby notify the congestion in the intermediate node.
Each node in the network should be able to add the WECN to thereby indicate a congestion as soon as a packet loss occurs. To reduce redundant adding of WECN, only one WECN
message is required to be set in a node, which is sufficient to notify the congestion. However, the WECN, which may be a single WECN bit, may be added in the following packets belonging to the same transmission or congestion window by different ones of successive routers passed by the data packets. As it takes a round-trip time from the first added WECN to reach the source A and the condition and buffer occupancy in each network node usually various greatly, not only one WECN is usually set in a transmission window during a round-trip time, because the first lost packet in each intermediate node may not occur at the same time. Thus, each WECN added in a transmission window belongs to a different transmitting network node which is allowed to add the WECN only once.
Fig. 3 shows a general diagram of an intermediate node 1 and an intermediate node 2, successively connected in the direction of the forward path. In the present case, both intermediate nodes 1 and 2 are congested. A WECN data packet having an added WECN is shown as a hatched square.
According to Fig. 3, a control means C1 arranged in the intermediate node 1 adds a WECN to the second data packet, since the first data packet is lost due to the congestion.
Furthermore, the third data packet is also lost due to the congestion. However, since the intermediate node 1 is only allowed to add the WECN once, the first data packet remains without a WECN addition. The data packet sequence is then transmitted via the forward path to the intermediate node 2, where the fifth and sixth data packets are lost due to the congestion. Accordingly, a WECN is added to the seventh data packet by a control means C2 of the intermediate node 2.
The TCP destination B receives the data packet sequence comprising the WECN packets number 2 and 7 and sets the WECN flags of the corresponding acknowledgment packets to be returned to the TCP source A.
In the forward path, the successive routers may not erase a WECN bit in arriving packets, to thereby maintain the WECN
compliance in the network. As the TCP destination B sets a WECN flag in the TCP header of an acknowledgment packet in response to each IP packet with an added WECN bit, the TCP
source A may receive a plurality of WECN packets coming from different intermediate nodes within a congestion window. Since the main function of WECN is to initiate a congestion control, i.e. to reduce the congestion window, only once in a transmission window in the event of a network congestion, these multiple WECN messages also provide a robustness against the possibility of dropping a WECN packet in the bi-directional transmitting path.
In order to comply with the currently proposed ECN
mechanism in the IETF draft, the congestion experienced information should be kept in the regular headers of an IP
packet, since the processing of the regular headers in IP
packets is more efficient than processing the header information in IP options. In the ECN mechanism, bit No. 6 and bit No. 7 of the IPv4 TOS octet are designated as the ECT bit and the CE bit, respectively. In addition thereto, bit No. 5 in the IPv4 TOS octet can be chosen as the WECN-Echo flag used to indicate congestion packet losses by intermediate routers or other network elements. Thereby, a different window reduction can be initiated by the WECN
congestion control.
Accordingly, when the TCP destination B receives a CE data packet, it sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. According to the different CE bit settings for the ECN and the WECN packets, two different flags of the TCP header are requirted. Since bit No. 9 is designated as the ECN-Echo flag of the TCP header, bit No.
8 can be used as the WECN-Echo flag. Thus, if any of the received data packets are CE packets with bit 5 setting, then the returned ACK has its WECN-Echo flag set. If any of the received data packets are CE packets with bit 7 setting, then the returned ACK has its ECN-Echo flag set.
As only one WECN is allowed to be added in an intermediate node, the number of WECN packets will not exceed the number of total network nodes to be passed by the data packet.
Thereby, the burden of providing an interphase facility between IP and TCP at the destination side can be relieved.
Thus, according to the above proposed WECN mechanism, since non-congestion packet losses are not allowed to initiate congestion control for the consideration of decoupling congestion control and retransmission strategies, end nodes detect dropped data packets by receiving a WECN message set by the intermediate network nodes just in times of buffer overflow, wherein the congestion response of the end nodes to a received CE packet is at least as strong as the congestion response to a dropped data packet which is independent of congestion control. There is also no need of particular implementations of TCP related to the ECN
mechanism proposed by ITEF, wherein TCP requires a less conservative response as compared to the case of a dropped packet, especially over small time scales, since a buffer overflow has not yet occurred.
The additional requirement for the TCP source A to react to multiple WECN acknowledgment packets is that it should not repeat the reduction of the congestion window since the packet was probably dropped before the TCP source A has reduced its congestion window in response to an earlier WECN acknowledgment packet. Thus, the TCP source A should react to a WECN acknowledgment packet at most once per round-trip time. This can be achieved by adapting the TCP
source A in such a manner that it reacts to a subsequent WECN acknowledgment packet only after the outstanding data packets, transmitted before the TCP source A entered into a loss recovery phase upon receiving the first WECN
acknowledgment packet, have all been acknowledged. Like in the ECN mechanism, the TCP could be changed so as to provide a negotiation phase during setup to determine if both end nodes are WECN capable.
The WECN mechanism according to the preferred embodiment of the present invention leads to an independence of the TCP
from the packet loss as an indicator of congestion. Since the TCP uses the WECN message to invoke congestion control whenever a packet loss occurs, only a retransmission mechanism is started as a response to a packet loss without a WECN message, such that the TCP data flow rate is not affected in such a case. This is very useful in wireless or mobile networks, since the network itself has the function of distinguishing different sources of packet losses. Thus, the TCP congestion window can only be reduced by the WECN
message which is set due to congestion losses.
Moreover, the TCP source A may only react once during a round-trip time and generally to the earliest one of received WECN and ECN ACKs. If an ECN ACK is received at first, the conventional congestion control is invoked at the TCP source A. However, when some packet losses due to congestion arrive before the ECN messages within a round-trip time, the WECN messages added just upon the first packet loss caused by the congestion will arrive in time to initiate a general congestion control e.g. with half reduction of window size instead of waiting for the later arrival of the ECN packets. Thus, WECN leads to a congestion control which is completely free from non-congestion lost packets and high performance is assured without having to resort to islands of different sources of packet losses in wireless and mobile networks.
The WECN mechanism according to the preferred embodiment of the present invention not only leads to a decoupling of congestion control from loss recovery but also contributes to the loss recovery phase. Since it is required that the WECN is set immediately after the packet loss occurs, it is very likely that the WECN acknowledgement packet arrives before the threshold number of duplicate acknowledgement packets. If this WECN message is used to trigger the transmission or retransmission of any data packets, it can increase the speed of entering the TCP recovery phase so as to quickly retransmit congestion-related lost packets.
However, the ECN cannot always be added immediately after a lost packet in case there are several successive packet losses or disordered packets before the arrival of the ECN
message. Thus, it cannot be judged which lost packet has triggered the addition of the ECN or if it was added without delay. Thus, it is suggested only applying ECN to quickly enter into the loss recovery phase, before the threshold duplicate acknowledgement packets arrive.
Otherwise, data transmission during loss recovery should be performed on the basis of the traditional fast retransmission and fast recovery algorithm.
Fig. 4 shows a diagram of transmissions between the TCP
source A and the TCP destination B, wherein the transmission of a first message X and a second message Y is depicted as a plurality of forward and backward arrows each indicating the transmission of a data packet and an acknowledgement packet (ACK), respectively. In the diagram, the transmission proceeds from the top to the bottom and corresponding ACK messages are indicated by the backward arrows from the destination B to the source A. Thus, a transmission window is indicated by the time period (vertical direction) from the starting point of a forward arrow to the end point of the corresponding backward arrow.
During the transmission of the message X, the second data packet is lost due to a congestion loss 1 notified to the TCP destination B by the subsequent third data packet.
Thus, an acknowledgement packet with a set WECN-Echo flag is returned to the TCP source A before any ECN message has arrived. Based on the received acknowledgment and duplicate acknowledgement with the set WECN-Echo flag, the TCP source A performs a congestion control by reducing SSTHRES to half of the current CWND value. Then, CWND is set equal to the new SSTHRES.
In the present case, an ECN is set delayed in the fifth data packet, such that an ECN-Echo flag is set in the corresponding ACK packet. At the TCP source A, the ACK with ECN-Echo flag is ignored, since the WECN ACK has already been received in the same transmission window (i.e. forward and backward arrow relating to the transmission of the message Y). Nevertheless, the conventional TCP fast retransmission algorithm is started for the lost packet 1, since the threshold number of duplicate ACKs, i.e. 3 ACKs, has been received.
Furthermore, an additional congestion loss 2 occurs at the sixth data packet, such that a WECN is set in the seventh data packet so as to initiate an ACK with a WECN-Echo flag.
However, the WECN message is also ignored at the TCP source A, since the ACK with WECN-Echo flag is also received within the above same transmission window. Again, the conventional TCP fast retransmission algorithm is performed for the lost packet 2 after the receipt of 3 duplicate ACKs.
Fig. 5 shows a diagram similar to the diagram according to Fig. 4, wherein a non-congestion loss 1 occurs during the transmission of the first data packet of the message X. In the present case, the treshold number of duplicate acknowledgements arrive at the TCP source A before the receipt of the ECN acknowledgment. Furthermore, a congestion loss 2 occurs during the transmission of the sixth data packet of the message X.
Since no WECN is added in response to the non-congestion loss 1, the conventional fast retransmission algorithm is performed, i.e. the lost data packet is retransmitted after three duplicate acknowledgments have been received.
Moreover, the conventional congestion control, e.g.
reduction of SSTHRES to 0.625CWND and setting of a new CWND
equal to the new SSTHRES, is performed in response to the receipt of the ECN acknowledgment. In the present example, a WECN is set in response to the non-congestion loss 2.
However, the corresponding WECN ACK is ignored, since it is received within the same transmission window. Nevertheless, due to the conventional retransmission algorithm, the lost packet 2 is retransmitted after the receipt of three duplicate acknowledgements.
Fig. 6 shows another transmission example, wherein an ECN
is set in a previous transmission window (message X) due to a detected congestion and, despite of the conventional congestion performed in response to the receipt of the ECN
ACK, a subsequent packet loss occurs in the following transmission window (message Y).
Due to the congestion loss, a WECN is set in the following data packet, and a WECN congestion control, i.e.
SSTHRES=1/2CWND and CWND=SSTHRES, according to the preferred embodiment of the present invention is performed in response to the receipt of the WECN ACK. Moreover, the conventional fast retransmission is performed after the receipt of three duplicate acknowledgements, to thereby retransmit the lost data packet. The subsequent ECN message is ignored due to its receipt within the same transmission window.
Fig. 7 shows a transmission example in which an ECN message is received before a subsequent non-congestion packet loss 1 and congestion packet loss 2 within the same transmission window.
According to Fig. 7, a conventional congestion control is performed in response to the receipt of the ECN ACK.
However, the non-congestion loss 1 does not initiate a WECN
message. After three duplicate ACKs, the conventional retransmission of the non-congestion loss 1 is performed.
The subsequent WECN ACK set in response to the congestion loss 2 is ignored at the TCP source A, since it has occurred in the same transmission window. Nevertheless, again, the conventional retransmission is performed after the receipt of three duplicate acknowlegments.
Fig. 8 shows a case in which the second and sixth data packets of a message X are lost due to congestion, and the seventh data packet is a disordered packet. Thus, WECN
messages are set in the third and eighth data packet, since the seventh data packet is a disordered one. The congestion control according to the preferred embodiment of the present invention is then performed in response to the receipt of the first WECN ACK. Thereafter, a conventional retransmission is performed in response to the receipt of three duplicate ACKs. However, the second WECN ACK which is accompanied by one duplicate WECN ACK (due to the disordered packet) is ignored, since it is received within the same transmission window. Nevertheless, the conven-tional retransmission is again performed for the lost packet 2 after the receipt of three duplicate ACKs. Since the disordered packet cannot be identified, a retrans-mission thereof is not possible.
In Fig. 9, a further transmission example is shown, wherein a non-congestion loss 1 (first data packet) and a later congestion loss 2 (fifth data packet) followed by a non-congestion loss 3 (sixth data packet) occur during the transmission of a message X.
The first non-congestion loss 1 does not initiate any congestion control procedure and leads to a conventional retransmission after the receipt of three duplicate ACKs.
Due to the immediately following non-congestion loss, the WECN set in the sixth data packet in response to the congestion loss 2 is not received at the TCP destination B.
Since the sixth data packet is lost due to the non-congestion loss 3, no WECN is set in the seventh data packet. Thus, the WECN ACK is transmitted in response to the receipt of the eighth data packet, to thereby initiate the congestion control procedure according to the preferred embodiment of the present invention. Due to the lost sixth and non-WECN seventh data packet, the WECN ACK is accompanied by two duplicate WECN ACKs. Thereafter, the losses 2 and 3 are retransmitted according to the conventional retransmission algorithm.
Finally, Fig. 10 shows a case in which three congestion losses 1 to 3 occur during the transmission of the message X, wherein the corresponding WECN are set delayed.
According to the conventional retransmission, each of the three lost data packets 1 to 3 is retransmitted by the TCP
source A in response to the receipt of the respective three duplicate ACKs (retransmission of lost packet 3 not shown).
In the present case, the congestion control procedure according the preferred embodiment of the present invention is delayed until the first WECN ACK has been received.
However, the subsequent WECN ACK within the same transmission window is ignored.
The above described ECN-based overload control method may be utilized in any packet network. According to the above description, the overload control can be performed without substantially changing the conventional overload control processing of the TCP.
Although the invention has been described here in connection with the preferred embodiment according to the attached drawings, it is clear that the invention is not limited to these examples, as it can be varied in several ways within the scope of the attached claims. As indicated above, a prerequisite for a user terminal is that it acknowledges correctly received (i.e. uncorrupted) data units. Therefore, the idea can in principal be applied to any other protocol which sends acknowledgments. As already said, the user terminals may have a wireless access to the network.
In summary, the invention relates to a method for controlling overload in a packet-switched network, especially a mobile or wireless network where the transmission control protocol (TCP) is used as the transport layer protocol. A congestion notification information is added to a data packet following a data packet lost due to a buffer overflow. This is an effective way to improve TCP performance in wireless and mobile networks, since congestion control can be performed completely independent from retransmissions. The proposed mechanism provides a simple way of introducing TCP
congestion avoidance control strategies into wireless and mobile networks. In addition, the congestion notification information should be added at least not later than a threshold number of following packets to thereby fasten the rate of congestion control initiation and loss recovery due to congestion.
It is therefore an object of the present invention to provide a method for controlling overload in a packet-switched network, and a packet-switched telecommunication network, by means of which an unnecessary reduction of the link bandwidth utilization can be prevented.
This object is achieved by a method for controlling overload in a packet-switched network comprising traffic sources, traffic destinations and network nodes, said method comprising the steps of:
transmitting data packets from one of said traffic sources to one of said traffic destinations;
transmitting an acknowledgment packet from said one traffic destination to said one traffic source, if a data packet has been received correctly at said one destination; and adding a congestion notification information to a data packet following a data packet lost due to a buffer overflow.
Additionally, the above object is achieved by a packet-switched telecommunication network comprising:
network nodes interconnected by transmission lines;
user terminals connected to said network nodes, said user terminals acting as traffic sources which transmit data packets and as traffic destinations which receive data packets;
detecting means for detecting a loss of a data packet due to a buffer overflow in one of said network nodes; and control means for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detection means.
Accordingly, a short-cut ECN mechanism (Wireless-ECN) which preferably can be used in wireless or mobile environments is provided. Like ELN, the mechanism is arranged to communicate the reason for a packet loss to the TCP source.
In particular, the source can be informed that a loss happened due to reasons related to a network congestion, such that congestion control can be decoupled from retransmissions. Thus, the congestion window is only reduced in case the congestion notification information has been received, without considering packet losses. By quickly informing the source that a loss happened due to reasons relating to a network congestion, congestion control and loss recovery mechanism can be separated. This mechanism is simple to implement and compatible with the existing TCP congestion control.
When Wireless-ECN is used in the traditional ECN
environment, Wireless-ECN is interpreted by the TCP source as a new instance of congestion. The integration of Wireless-ECN into the known ECN mechanism allows congestion control to be initiated by WECN or ECN messages. Since a WECN message should be added at least not later than the threshold number of following packets, it may invoke congestion control even sooner than with the fast retransmission mechanism. The integration of the WECN into the ECN mechanism not only avoids unnecessary congestion-induced packet losses, but also prevents the unnecessary delayed initiation of congestion control which often occurs due to a loss of an ECN packet or an inefficient effect of the ECN mechanism or other exceptions in the ECN mechanism.
Preferably, said following data packet directly follows said lost data packet. This ensures that the congestion notification information can inevitably by added even with multiple packet losses, and there is no need for mechanism in the router to monitor the average queue size. Since the congestion notification information is added as quickly as possible after a packet loss has occurred due to congestion, it is ensured that a network congestion is alleviated in time.
Furthermore, the congestion notification may be added in the header of said following data packet. In this case, bit No. 5 in the IPv 4 TOS octet can be used, for example.
Preferably, each of the network nodes should be able to add the congestion notification information to thereby indicate a congestion-related data loss. Thereby, multiple WECN
messages provide a robustness against the possibility of dropping a WECN packet in the bi-directional transmitting paths.
The congestion notification information is allowed to be added to those following data packets which belong to the same congestion window in the successively past routers.
Moreover, each network node is allowed to add the congestion information only once. Thus each congestion notification information added in a transmission window belongs to another network node.
Having received a data packet with an added congestion notification information, the traffic destination preferably sets a congestion notification flag in the header of an acknowledgment packet. The congestion notification flag may be bit No. 8 in the TCP header of the _ g _ subsequent acknowledgment packet. Since the TCP uses the WECN message to invoke congestion control, only a retransmission mechanism is performed in case of a packet loss without a WECN message. Thus, the TCP data flow rate is not affected. This is very useful in wireless or mobile networks, since the network itself has the function of distinguishing different sources of packet losses. By notifying the source with a WECN acknowledgment packet whenever a congestion-related loss has occurred, packet losses due to transmission errors cannot reduce the TCP
flow control window (congestion window), which results in a significant performance improvement. The congestion window can only be reduced by the congestion notification flag set due to a congestion loss.
Preferably, a congestion processing is repeated at the traffic source only after the outstanding data packets transmitted before the first receipt of a congestion notification flag have all been acknowledged. Thereby, reduction of the congestion window is not repeated, if the packet was dropped before the source reduced its window in response to the congestion notification flag.
The WECN mechanism according to the present invention enables complete decoupling of the congestion control function from packet losses. Compared to ECN, the WECN
notification may inevitably be added, since the dropped packets give the buffer time to vacate some space for holding and transmitting new data. In case a WECN is lost, e.g. in a high loss link condition where all WECN
notifications are lost in a control cycle, or in case only one WECN is added in a transmission window and this WECN is lost by accident, this loss will result in a failure of congestion control for that flow and an increased congestion of the network, since the assumed source of data loss was not a congestion. Nevertheless, other WECNs are added for subsequent dropped packets in the next congestion window. Thus, the mechanism is very secure and robust compared to the ECN mechanism where the loss of an ECN will not cause another addition of an ECN packet.
According to the present invention, no packet losses need to be considered to invoke congestion window reduction.
Since mechanisms for monitoring-the average queue size are not required in the routers, the WECN mechanism can be implemented in a simple manner and opens the way to a further deployment of the ECN mechanism. It is to be noted that the WECN mechanism is compatible with all TCP
congestion control mechanisms, as long as they are invoked by packet losses, and it is easy to incorporate them into wireless and mobile networks. With the incremental deployment of the ECN mechanism, the integration of WECN
into ECN may allow congestion control to be initiated by WECN or ECN messages and WECN packet functions only if a packet lost due to a congestion arrives earlier than an ECN
within the corresponding data window. With the addition of WECN to the Fast-TCP mechanism, the window reduction could be invoked by WECN when a buffer overflow occurs, since the TCP behavior at the end systems is not changed. Thus, this is an effective way of inproving TCP performance in wireless and mobile networks.
In addition, since WECN is required to be added not later than after a threshold number of duplicate acknowledgements, improved TCP performance in wired network environments can be expected, since the initiation of congestion control is accelerated by the WECN message.
Moreover, if this message is used for triggering the transmission or retransmission data packets, it can hasten the speed of entering into the TCP recovery phase due to congestion, such that congestion-induced lost packets are quickly retransmitted.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following, the present invention will be described in greater detail on the basis of a preferred embodiment with reference to the accompanying drawings, in which:
Fig. 1 shows a general block diagram of a flow control loop in a TCP over ATM network, in which the preferred embodiment of the present invention is implemented;
Fig. 2 shows a general block diagram of an intermediate node arranged between a traffic source and a traffic destination, according to the preferred embodiment of the present invention;
Fig. 3 shows a general block diagram of two subsequent intermediate nodes according to the preferred embodiment of the present invention;
Fig. 4 shows a diagram of transmissions between a traffic source and a traffic destination, in case a wireless congestion notification (WECN) arrives at the traffic source before a usual congestion notification (ECN) within the same transmission window;
Fig. 5 shows a diagram of transmissions between the traffic source and the traffic destination, in case a non-congestion packet loss is detected before a congestion notification within the same transmission window;
Fig. 6 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN arrives at the traffic source after an ineffective ECN
implementation in the preceding transmission window;
Fig. 7 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN is received at the traffic source after a normal ECN within the same transmission window;
Fig. 8 shows a diagram of transmissions between the traffic source and the traffic destination, in case a WECN is set before three following packets in the same transmission window;
Fig. 9 shows a diagram of transmissions between the traffic source and the traffic destination, in case of a WECN and a non-congestion packet loss within the same transmission window; and Fig. 10 shows a diagram of transmissions between the traffic source and the traffic destination, in case of a delayed set of WECN and multiple congestion losses within the same transmission window.
DESCRIPTION OF THE PREFERRED EMBODIMENT
In the following the preferred embodiment of the present invention will be described on the basis of a TCP over ATM
network as shown in Fig. 1.
ATM (Asynchronous Transfer Mode) is a connection-oriented packet-switching technique which the international telecommunication standardization organization ITU-T has chosen as the target solution of the broadband Integrated Services Digital Network (B-ISDN). The problems of conventional packet networks have been eliminated in the ADM network by using short packets of a standard length (53 bytes), known as cells. ATM networks are quickly being adopted as backbones for the various parts of TCP/IP
networks such as the Internet. This also applies to wireless or mobile networks.
According to Fig. 1, a connection between two user terminals A and B in the TCP over ATM network is shown, i.e. the user terminals using TCP as a transport layer protocol. In addition, two access nodes AN1 and AN2 of the user terminals, one intermediate node N1 and transmission lines TL1, TL2 connecting the nodes are shown.
After an initial handshake has been completed, the user terminals A and B begin to transmit data by means of TCP
segments. The term "segment" refers to the unit of information passed by TCP to IP (Internet protocol). IP
headers are attached to these TCP segments to form IP
datagrams, i.e. TCP segments are transferred to the receiver within IP datagrams as the information units used by IP. Each uncorrupted TCP segment including the hand shaking segments, is acknowledged. To illustrate the function of the flow control loop, it is assumed that the user terminal A transmits one TCP segment to the user terminal B. At the network layer, the user terminal A adds an IP header to this TCP segment to form an IP datagram.
This datagram is converted into standard ATM cells in the access node AN1 located at the edge of the ATM network ANW.
The cells of the datagram are then routed through the ATM
network to the access node AN2 of the user terminal B. This access node reconstructs the original IP datagram from the arriving cells and sends the IP datagram to the user terminal B. The user terminal B removes the IP header to reveal the TCP segment. If the segment is received correctly, the user terminal B sends an acknowledging TCP
segment ACK back to the user terminal A.
TCP is one of the few transport protocols that natively has a congestion control mechanism. The preferred embodiment of the present invention relies on this known TCP control mechanism. Therefore, this mechanism is described briefly in the following.
TCP congestion control is based on two variables: the receiver's advertised window (Wrcvr) and the congestion window (CNWD). The receiver's advertised window is maintained at the receiver as a measure of the buffering capacity of the receiver, and the congestion window is maintained at the transmitter as a measure of the capacity of the network. The TCP source can never transmit more segments than the minimum of the receiver's advertised window and the congestion window.
The TCP congestion control method comprises two phases:
slow start and congestion avoidance. A variable called SSTHRES (Slow Start Threshold) is maintained at the source to distinguish between the two phases. The source starts to transmit in the slow start phase by sending one TCP
segment, i.e. the value of CWND is set to one at the beginning. When the source receives an acknowledgment, it increments CWND by one, and, as a consequence, transmits to more segments. In this way the value of CWND doubles every round trip time during the slow start phase, as each segment is acknowledged by the destination terminal. The slow start phase ends and the congestion avoidance phase begins, when CWND reaches the value of SSTHRES.
If a data packet is lost in a TCP connection, the source does not receive an acknowledgment and performs a loss recovery operation.
By duplicating the acknowledgments, the TCP source can be made to slow down its output rate. This is based on the fast retransmission and fast recovery algorithms which the source automatically performs after receiving a certain number of duplicate acknowledgments. These algorithms are widely implemented in different TCP versions. According to the algorithms, the source performs, after having received a predetermined threshold number of acknowledgments (e. g.
three acknowledgements), a retransmission of what appears to be the missing segment, without waiting for the expiry of a retransmission timer (fast retransmission algorithm).
After this, the source performs congestion avoidance, instead of slow start, in order not to reduce the data flow abruptly (fast recovery algorithm).
Fig. 2 shows a general diagram of an intermediate node connected to a TCP source A and a TCP destination B, which both may be workstations or the like. In the intermediate node, a congestion is shown as a black star, a passing data packet as a solid square, and a data packet lost due to the congestion as a doted square.
According to the preferred embodiment of the present invention, a Wireless-ECN (WECN) control means C is provided in the intermediate node, which is arranged to mark a data packet with an explicit wireless congestion notification (WECN) immediately after a packet loss has occurred due to a buffer overflow which may be detected by a detecting means (not shown). The detecting means may be included in the control means C or may be a separate means in the intermediate node.
If a first lost packet due to a buffer overflow in the intermediate node or router is detected within a transmission window of the TCP source A, a WECN is added in the header of the immediately following passing packet. The required time for this operation is available due to the dropped data packet which results in additional buffer time. Thus, the WECN is added as quickly as possible after a packet loss, such that the network congestion can be alleviated as soon as possible.
Furthermore, an arrow at the bottom of Fig. 2 shows the transmitting path of the WECN, wherein the TCP destination B sets a WECN flag in the header of an acknowledgment packet in response to the receipt of a WECN data packet, to thereby notify the congestion in the intermediate node.
Each node in the network should be able to add the WECN to thereby indicate a congestion as soon as a packet loss occurs. To reduce redundant adding of WECN, only one WECN
message is required to be set in a node, which is sufficient to notify the congestion. However, the WECN, which may be a single WECN bit, may be added in the following packets belonging to the same transmission or congestion window by different ones of successive routers passed by the data packets. As it takes a round-trip time from the first added WECN to reach the source A and the condition and buffer occupancy in each network node usually various greatly, not only one WECN is usually set in a transmission window during a round-trip time, because the first lost packet in each intermediate node may not occur at the same time. Thus, each WECN added in a transmission window belongs to a different transmitting network node which is allowed to add the WECN only once.
Fig. 3 shows a general diagram of an intermediate node 1 and an intermediate node 2, successively connected in the direction of the forward path. In the present case, both intermediate nodes 1 and 2 are congested. A WECN data packet having an added WECN is shown as a hatched square.
According to Fig. 3, a control means C1 arranged in the intermediate node 1 adds a WECN to the second data packet, since the first data packet is lost due to the congestion.
Furthermore, the third data packet is also lost due to the congestion. However, since the intermediate node 1 is only allowed to add the WECN once, the first data packet remains without a WECN addition. The data packet sequence is then transmitted via the forward path to the intermediate node 2, where the fifth and sixth data packets are lost due to the congestion. Accordingly, a WECN is added to the seventh data packet by a control means C2 of the intermediate node 2.
The TCP destination B receives the data packet sequence comprising the WECN packets number 2 and 7 and sets the WECN flags of the corresponding acknowledgment packets to be returned to the TCP source A.
In the forward path, the successive routers may not erase a WECN bit in arriving packets, to thereby maintain the WECN
compliance in the network. As the TCP destination B sets a WECN flag in the TCP header of an acknowledgment packet in response to each IP packet with an added WECN bit, the TCP
source A may receive a plurality of WECN packets coming from different intermediate nodes within a congestion window. Since the main function of WECN is to initiate a congestion control, i.e. to reduce the congestion window, only once in a transmission window in the event of a network congestion, these multiple WECN messages also provide a robustness against the possibility of dropping a WECN packet in the bi-directional transmitting path.
In order to comply with the currently proposed ECN
mechanism in the IETF draft, the congestion experienced information should be kept in the regular headers of an IP
packet, since the processing of the regular headers in IP
packets is more efficient than processing the header information in IP options. In the ECN mechanism, bit No. 6 and bit No. 7 of the IPv4 TOS octet are designated as the ECT bit and the CE bit, respectively. In addition thereto, bit No. 5 in the IPv4 TOS octet can be chosen as the WECN-Echo flag used to indicate congestion packet losses by intermediate routers or other network elements. Thereby, a different window reduction can be initiated by the WECN
congestion control.
Accordingly, when the TCP destination B receives a CE data packet, it sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. According to the different CE bit settings for the ECN and the WECN packets, two different flags of the TCP header are requirted. Since bit No. 9 is designated as the ECN-Echo flag of the TCP header, bit No.
8 can be used as the WECN-Echo flag. Thus, if any of the received data packets are CE packets with bit 5 setting, then the returned ACK has its WECN-Echo flag set. If any of the received data packets are CE packets with bit 7 setting, then the returned ACK has its ECN-Echo flag set.
As only one WECN is allowed to be added in an intermediate node, the number of WECN packets will not exceed the number of total network nodes to be passed by the data packet.
Thereby, the burden of providing an interphase facility between IP and TCP at the destination side can be relieved.
Thus, according to the above proposed WECN mechanism, since non-congestion packet losses are not allowed to initiate congestion control for the consideration of decoupling congestion control and retransmission strategies, end nodes detect dropped data packets by receiving a WECN message set by the intermediate network nodes just in times of buffer overflow, wherein the congestion response of the end nodes to a received CE packet is at least as strong as the congestion response to a dropped data packet which is independent of congestion control. There is also no need of particular implementations of TCP related to the ECN
mechanism proposed by ITEF, wherein TCP requires a less conservative response as compared to the case of a dropped packet, especially over small time scales, since a buffer overflow has not yet occurred.
The additional requirement for the TCP source A to react to multiple WECN acknowledgment packets is that it should not repeat the reduction of the congestion window since the packet was probably dropped before the TCP source A has reduced its congestion window in response to an earlier WECN acknowledgment packet. Thus, the TCP source A should react to a WECN acknowledgment packet at most once per round-trip time. This can be achieved by adapting the TCP
source A in such a manner that it reacts to a subsequent WECN acknowledgment packet only after the outstanding data packets, transmitted before the TCP source A entered into a loss recovery phase upon receiving the first WECN
acknowledgment packet, have all been acknowledged. Like in the ECN mechanism, the TCP could be changed so as to provide a negotiation phase during setup to determine if both end nodes are WECN capable.
The WECN mechanism according to the preferred embodiment of the present invention leads to an independence of the TCP
from the packet loss as an indicator of congestion. Since the TCP uses the WECN message to invoke congestion control whenever a packet loss occurs, only a retransmission mechanism is started as a response to a packet loss without a WECN message, such that the TCP data flow rate is not affected in such a case. This is very useful in wireless or mobile networks, since the network itself has the function of distinguishing different sources of packet losses. Thus, the TCP congestion window can only be reduced by the WECN
message which is set due to congestion losses.
Moreover, the TCP source A may only react once during a round-trip time and generally to the earliest one of received WECN and ECN ACKs. If an ECN ACK is received at first, the conventional congestion control is invoked at the TCP source A. However, when some packet losses due to congestion arrive before the ECN messages within a round-trip time, the WECN messages added just upon the first packet loss caused by the congestion will arrive in time to initiate a general congestion control e.g. with half reduction of window size instead of waiting for the later arrival of the ECN packets. Thus, WECN leads to a congestion control which is completely free from non-congestion lost packets and high performance is assured without having to resort to islands of different sources of packet losses in wireless and mobile networks.
The WECN mechanism according to the preferred embodiment of the present invention not only leads to a decoupling of congestion control from loss recovery but also contributes to the loss recovery phase. Since it is required that the WECN is set immediately after the packet loss occurs, it is very likely that the WECN acknowledgement packet arrives before the threshold number of duplicate acknowledgement packets. If this WECN message is used to trigger the transmission or retransmission of any data packets, it can increase the speed of entering the TCP recovery phase so as to quickly retransmit congestion-related lost packets.
However, the ECN cannot always be added immediately after a lost packet in case there are several successive packet losses or disordered packets before the arrival of the ECN
message. Thus, it cannot be judged which lost packet has triggered the addition of the ECN or if it was added without delay. Thus, it is suggested only applying ECN to quickly enter into the loss recovery phase, before the threshold duplicate acknowledgement packets arrive.
Otherwise, data transmission during loss recovery should be performed on the basis of the traditional fast retransmission and fast recovery algorithm.
Fig. 4 shows a diagram of transmissions between the TCP
source A and the TCP destination B, wherein the transmission of a first message X and a second message Y is depicted as a plurality of forward and backward arrows each indicating the transmission of a data packet and an acknowledgement packet (ACK), respectively. In the diagram, the transmission proceeds from the top to the bottom and corresponding ACK messages are indicated by the backward arrows from the destination B to the source A. Thus, a transmission window is indicated by the time period (vertical direction) from the starting point of a forward arrow to the end point of the corresponding backward arrow.
During the transmission of the message X, the second data packet is lost due to a congestion loss 1 notified to the TCP destination B by the subsequent third data packet.
Thus, an acknowledgement packet with a set WECN-Echo flag is returned to the TCP source A before any ECN message has arrived. Based on the received acknowledgment and duplicate acknowledgement with the set WECN-Echo flag, the TCP source A performs a congestion control by reducing SSTHRES to half of the current CWND value. Then, CWND is set equal to the new SSTHRES.
In the present case, an ECN is set delayed in the fifth data packet, such that an ECN-Echo flag is set in the corresponding ACK packet. At the TCP source A, the ACK with ECN-Echo flag is ignored, since the WECN ACK has already been received in the same transmission window (i.e. forward and backward arrow relating to the transmission of the message Y). Nevertheless, the conventional TCP fast retransmission algorithm is started for the lost packet 1, since the threshold number of duplicate ACKs, i.e. 3 ACKs, has been received.
Furthermore, an additional congestion loss 2 occurs at the sixth data packet, such that a WECN is set in the seventh data packet so as to initiate an ACK with a WECN-Echo flag.
However, the WECN message is also ignored at the TCP source A, since the ACK with WECN-Echo flag is also received within the above same transmission window. Again, the conventional TCP fast retransmission algorithm is performed for the lost packet 2 after the receipt of 3 duplicate ACKs.
Fig. 5 shows a diagram similar to the diagram according to Fig. 4, wherein a non-congestion loss 1 occurs during the transmission of the first data packet of the message X. In the present case, the treshold number of duplicate acknowledgements arrive at the TCP source A before the receipt of the ECN acknowledgment. Furthermore, a congestion loss 2 occurs during the transmission of the sixth data packet of the message X.
Since no WECN is added in response to the non-congestion loss 1, the conventional fast retransmission algorithm is performed, i.e. the lost data packet is retransmitted after three duplicate acknowledgments have been received.
Moreover, the conventional congestion control, e.g.
reduction of SSTHRES to 0.625CWND and setting of a new CWND
equal to the new SSTHRES, is performed in response to the receipt of the ECN acknowledgment. In the present example, a WECN is set in response to the non-congestion loss 2.
However, the corresponding WECN ACK is ignored, since it is received within the same transmission window. Nevertheless, due to the conventional retransmission algorithm, the lost packet 2 is retransmitted after the receipt of three duplicate acknowledgements.
Fig. 6 shows another transmission example, wherein an ECN
is set in a previous transmission window (message X) due to a detected congestion and, despite of the conventional congestion performed in response to the receipt of the ECN
ACK, a subsequent packet loss occurs in the following transmission window (message Y).
Due to the congestion loss, a WECN is set in the following data packet, and a WECN congestion control, i.e.
SSTHRES=1/2CWND and CWND=SSTHRES, according to the preferred embodiment of the present invention is performed in response to the receipt of the WECN ACK. Moreover, the conventional fast retransmission is performed after the receipt of three duplicate acknowledgements, to thereby retransmit the lost data packet. The subsequent ECN message is ignored due to its receipt within the same transmission window.
Fig. 7 shows a transmission example in which an ECN message is received before a subsequent non-congestion packet loss 1 and congestion packet loss 2 within the same transmission window.
According to Fig. 7, a conventional congestion control is performed in response to the receipt of the ECN ACK.
However, the non-congestion loss 1 does not initiate a WECN
message. After three duplicate ACKs, the conventional retransmission of the non-congestion loss 1 is performed.
The subsequent WECN ACK set in response to the congestion loss 2 is ignored at the TCP source A, since it has occurred in the same transmission window. Nevertheless, again, the conventional retransmission is performed after the receipt of three duplicate acknowlegments.
Fig. 8 shows a case in which the second and sixth data packets of a message X are lost due to congestion, and the seventh data packet is a disordered packet. Thus, WECN
messages are set in the third and eighth data packet, since the seventh data packet is a disordered one. The congestion control according to the preferred embodiment of the present invention is then performed in response to the receipt of the first WECN ACK. Thereafter, a conventional retransmission is performed in response to the receipt of three duplicate ACKs. However, the second WECN ACK which is accompanied by one duplicate WECN ACK (due to the disordered packet) is ignored, since it is received within the same transmission window. Nevertheless, the conven-tional retransmission is again performed for the lost packet 2 after the receipt of three duplicate ACKs. Since the disordered packet cannot be identified, a retrans-mission thereof is not possible.
In Fig. 9, a further transmission example is shown, wherein a non-congestion loss 1 (first data packet) and a later congestion loss 2 (fifth data packet) followed by a non-congestion loss 3 (sixth data packet) occur during the transmission of a message X.
The first non-congestion loss 1 does not initiate any congestion control procedure and leads to a conventional retransmission after the receipt of three duplicate ACKs.
Due to the immediately following non-congestion loss, the WECN set in the sixth data packet in response to the congestion loss 2 is not received at the TCP destination B.
Since the sixth data packet is lost due to the non-congestion loss 3, no WECN is set in the seventh data packet. Thus, the WECN ACK is transmitted in response to the receipt of the eighth data packet, to thereby initiate the congestion control procedure according to the preferred embodiment of the present invention. Due to the lost sixth and non-WECN seventh data packet, the WECN ACK is accompanied by two duplicate WECN ACKs. Thereafter, the losses 2 and 3 are retransmitted according to the conventional retransmission algorithm.
Finally, Fig. 10 shows a case in which three congestion losses 1 to 3 occur during the transmission of the message X, wherein the corresponding WECN are set delayed.
According to the conventional retransmission, each of the three lost data packets 1 to 3 is retransmitted by the TCP
source A in response to the receipt of the respective three duplicate ACKs (retransmission of lost packet 3 not shown).
In the present case, the congestion control procedure according the preferred embodiment of the present invention is delayed until the first WECN ACK has been received.
However, the subsequent WECN ACK within the same transmission window is ignored.
The above described ECN-based overload control method may be utilized in any packet network. According to the above description, the overload control can be performed without substantially changing the conventional overload control processing of the TCP.
Although the invention has been described here in connection with the preferred embodiment according to the attached drawings, it is clear that the invention is not limited to these examples, as it can be varied in several ways within the scope of the attached claims. As indicated above, a prerequisite for a user terminal is that it acknowledges correctly received (i.e. uncorrupted) data units. Therefore, the idea can in principal be applied to any other protocol which sends acknowledgments. As already said, the user terminals may have a wireless access to the network.
In summary, the invention relates to a method for controlling overload in a packet-switched network, especially a mobile or wireless network where the transmission control protocol (TCP) is used as the transport layer protocol. A congestion notification information is added to a data packet following a data packet lost due to a buffer overflow. This is an effective way to improve TCP performance in wireless and mobile networks, since congestion control can be performed completely independent from retransmissions. The proposed mechanism provides a simple way of introducing TCP
congestion avoidance control strategies into wireless and mobile networks. In addition, the congestion notification information should be added at least not later than a threshold number of following packets to thereby fasten the rate of congestion control initiation and loss recovery due to congestion.
Claims (24)
1. A method for controlling overload in a packet-switched network, comprising traffic sources (A), traffic destinations (B) and network nodes (AN, N1), said method comprising the steps of:
a) transmitting data packets from one of said traffic sources to one of said traffic destinations;
b) transmitting an acknowledgment packet from said one traffic destination to said one traffic source, if a data packet has been received correctly at said one destination;
and c) adding a congestion notification information to a data packet following a data packet lost due to a buffer overflow, for which lost data packet the source does not receive an acknowledgement, and wherein a retransmission operation is performed after a predetermined number of duplicate acknowledgements have been received.
a) transmitting data packets from one of said traffic sources to one of said traffic destinations;
b) transmitting an acknowledgment packet from said one traffic destination to said one traffic source, if a data packet has been received correctly at said one destination;
and c) adding a congestion notification information to a data packet following a data packet lost due to a buffer overflow, for which lost data packet the source does not receive an acknowledgement, and wherein a retransmission operation is performed after a predetermined number of duplicate acknowledgements have been received.
2. A method according to claim 1, wherein said following data packet directly follows said lost data packet.
3. A method according to claim 1 or 2, wherein said congestion notification information is added in the header of said following data packet.
4. A method according to anyone of the preceding claims, wherein said congestion notification information can be added by each of said network nodes to thereby indicate a congestion-related data loss.
5. A method according to anyone of the preceding claims, wherein said congestion notification information is allowed to be added by successive network nodes in following data packets belonging to the same congestion window.
6. A method according to anyone of the preceding claims, wherein each network node is allowed to add said congestion information only once.
7. A method according to anyone of the preceding claims, wherein said traffic destination sets a congestion notification flag in the header of an acknowledgment packet in response to a received data packet with an added congestion notification information.
8. A method according to anyone of the preceding claims, wherein said added congestion notification information is bit No. 5 in the IPv4 TOS octet.
9. A method according to claim 7, wherein said congestion notification flag is bit No. 8 in the TCP header of said acknowledgment packet.
10. A method according to anyone of the preceding claims, wherein a congestion processing is repeated at said traffic source only after the outstanding data packets transmitted before the receipt of the first congestion notification flag have all been acknowledged.
11. A method according to anyone of the preceding claims, wherein a congestion window is reduced in response to the receipt of said congestion notification flag.
12. A method according to claim 11, wherein said congestion window is reduced only if said congestion notification flag has been received before the arrival of a predetermined number of duplicate acknowledgments relating to the lost data packet.
13. A packet-switched telecommunication network comprising:
a) network nodes (AN1, AN2, N1) interconnected by transmission lines (TL1, TL2);
b) user terminals connected to said network nodes, said user terminals acting as traffic sources (A) which transmit data packets and as traffic destinations (B) which receive data packets;
c) detecting means for detecting a loss of a data packet due to a buffer overflow in one of said network nodes, for which lost data packetsthe source does not receive an acknowledgement; and d) control means (C) for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detecting means, and wherein said user terminals acting as traffic sources (A) are arranged to only perform a retransmission after a predetermined number of duplicate acknowledgements have been received.
a) network nodes (AN1, AN2, N1) interconnected by transmission lines (TL1, TL2);
b) user terminals connected to said network nodes, said user terminals acting as traffic sources (A) which transmit data packets and as traffic destinations (B) which receive data packets;
c) detecting means for detecting a loss of a data packet due to a buffer overflow in one of said network nodes, for which lost data packetsthe source does not receive an acknowledgement; and d) control means (C) for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detecting means, and wherein said user terminals acting as traffic sources (A) are arranged to only perform a retransmission after a predetermined number of duplicate acknowledgements have been received.
14. A telecommunication network according to claim 13, wherein said detecting means (10) are provided in at least one of said network nodes.
15. A telecommunication network according to claim 13 or 14, wherein said control means (C) is arranged to add said congestion notification information only ones in a transmission window.
16. A telecommunication network according to anyone of claims 13 to 15, wherein said user terminals acting as traffic destinations (B) are arranged to set a congestion notification flag in the header of an acknowledgment packet in response to the receipt of a data packet with said added congestion notification information.
17. A telecommunication network according to anyone of claims 13 to 16, wherein said user terminals acting as traffic sources (A) are arranged to perform congestion control in response to the receipt of a said congestion notification flag.
18. A telecommunication network according to claim 17, wherein said congestion control comprises reducing a congestion window.
19. A telecommunication network according to anyone of claims 13 to 18, wherein said user terminals acting as traffic sources (A) are arranged to react to a subsequent congestion notification flag only after outstanding data packets, transmitted before entering a loss recovery phase upon receiving the first congestion notification flag, have all been acknowledged.
20. A telecommunication network according to anyone of claims 13 to 19, wherein said packet-switched network is a mobile or wireless network.
21. A telecommunication network according to anyone of claims 13 to 20, wherein TCP is implemented in said telecommunication network.
22. A network node for a packet-switched telecommunication network, comprising:
a) detecting means for detecting a loss of a data packet due to a buffer overflow in said network node, for which lost data packet the source does not receive an acknowledgement; and b) control means (C) for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detecting means.
a) detecting means for detecting a loss of a data packet due to a buffer overflow in said network node, for which lost data packet the source does not receive an acknowledgement; and b) control means (C) for adding a congestion notification information to a data packet following a data packet lost due to said buffer overflow, in response to a detection result of said detecting means.
23. A network node according to claim 22, wherein said control means (C) is arranged to add said congestion notification information only ones in a transmission window.
24. A network node according to claim 22 or 23, wherein said following data packet is a data packet directly following said lost data packet.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP1999/002856 WO2000065782A1 (en) | 1999-04-27 | 1999-04-27 | Overload control method for a packet-switched network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2372023A1 true CA2372023A1 (en) | 2000-11-02 |
Family
ID=8167276
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002372023A Abandoned CA2372023A1 (en) | 1999-04-27 | 1999-04-27 | Overload control method for a packet-switched network |
Country Status (5)
| Country | Link |
|---|---|
| AU (1) | AU4034299A (en) |
| CA (1) | CA2372023A1 (en) |
| DE (1) | DE19983951B4 (en) |
| GB (1) | GB2364615B (en) |
| WO (1) | WO2000065782A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102255808A (en) * | 2011-07-08 | 2011-11-23 | 福建星网锐捷网络有限公司 | Congestion notification method, device, system and network equipment |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1249972A1 (en) * | 2001-04-09 | 2002-10-16 | Telefonaktiebolaget L M Ericsson (Publ) | Method of controlling a queue buffer |
| US20060253622A1 (en) * | 2003-01-28 | 2006-11-09 | Henning Wiemann | Method and device for congestion notification in packet networks indicating several different congestion causes |
| US7760646B2 (en) | 2005-02-09 | 2010-07-20 | Nokia Corporation | Congestion notification in 3G radio access |
| DE102008013349B4 (en) | 2008-03-10 | 2017-07-06 | Hytera Mobilfunk Gmbh | Communication method and communication system with packet distance and packet length control |
| US20140334296A1 (en) * | 2013-05-13 | 2014-11-13 | Futurewei Technologies, Inc. | Aggressive Transmission Control Protocol (TCP) Retransmission |
| US10079762B1 (en) * | 2017-04-24 | 2018-09-18 | Teradyne, Inc. | Test communication protocol |
| IT201900022458A1 (en) * | 2019-11-29 | 2021-05-29 | Telecom Italia Spa | Measurement of round-trip packet loss in a packet-switched communications network |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US567542A (en) * | 1896-09-08 | Brick rougher and sander |
-
1999
- 1999-04-27 WO PCT/EP1999/002856 patent/WO2000065782A1/en active Application Filing
- 1999-04-27 CA CA002372023A patent/CA2372023A1/en not_active Abandoned
- 1999-04-27 DE DE19983951T patent/DE19983951B4/en not_active Expired - Fee Related
- 1999-04-27 GB GB0125202A patent/GB2364615B/en not_active Expired - Fee Related
- 1999-04-27 AU AU40342/99A patent/AU4034299A/en not_active Abandoned
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102255808A (en) * | 2011-07-08 | 2011-11-23 | 福建星网锐捷网络有限公司 | Congestion notification method, device, system and network equipment |
| CN102255808B (en) * | 2011-07-08 | 2014-04-23 | 福建星网锐捷网络有限公司 | Congestion notification method, device, system and network equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| DE19983951T1 (en) | 2002-10-10 |
| WO2000065782A1 (en) | 2000-11-02 |
| GB2364615B (en) | 2004-03-31 |
| GB2364615A (en) | 2002-01-30 |
| DE19983951B4 (en) | 2009-06-25 |
| GB0125202D0 (en) | 2001-12-12 |
| AU4034299A (en) | 2000-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7369498B1 (en) | Congestion control method for a packet-switched network | |
| US6625118B1 (en) | Receiver based congestion control | |
| US6741555B1 (en) | Enhancement of explicit congestion notification (ECN) for wireless network applications | |
| EP1295428B1 (en) | Performance enhancement of transmission control protocol (tcp) for wireless network applications | |
| US6535482B1 (en) | Congestion notification from router | |
| EP1393508B1 (en) | Data transport acceleration and management within a network communication system | |
| US6697331B1 (en) | Link layer acknowledgement and retransmission for cellular telecommunications | |
| US20040192312A1 (en) | Communication system for voice and data with wireless TCP server | |
| US20070121506A1 (en) | Efficient loss recovery architecture for loss-decoupled tcp | |
| EP1344359B1 (en) | Method of enhancing the efficiency of data flow in communication systems | |
| Samaraweera et al. | Reinforcement of TCP error recovery for wireless communication | |
| EP1798913B1 (en) | Transport control method in wireless communication system | |
| EP0955749A1 (en) | Receiver based congestion control and congestion notification from router | |
| Wang et al. | Use of TCP decoupling in improving TCP performance over wireless networks | |
| US7203162B2 (en) | Link state retransmission mechanism | |
| CA2372023A1 (en) | Overload control method for a packet-switched network | |
| Peng et al. | An effective way to improve TCP performance in wireless/mobile networks | |
| Balakrishnan et al. | TCP improvements for heterogeneous networks: The Daedalus approach | |
| JP2001168871A (en) | Data transfer system | |
| JP4531302B2 (en) | Packet relay apparatus and method thereof | |
| Rani et al. | Cross layer based schemes for improving the performance of TCP in wireless networks | |
| Cohen et al. | Balanced packet discard for improving TCP performance in ATM networks | |
| Cerdà et al. | Study of the TCP Unfairness in a Wireless Environment | |
| Rani et al. | Enhancing TCP Performance by Detecting Spurious RTO in Wireless Network | |
| Buntinas | Congestion control schemes for tcp/ip networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |