DE19983951B4 - Overload control method for a packet-switched network - Google Patents

Abstract

Procedure with
Controlling congestion in a packet-switched network comprising traffic sources (A), traffic destinations (B) and network nodes (AN, N1) using the transmission control protocol (TCP) as a transport layer protocol; and
Forwarding data packets and corresponding acknowledgments between a traffic source and a traffic destination,
characterized in that the controlling comprises:
Adding, at a network node, congestion notification information to a data packet following a data packet lost due to a cache overflow, thereby indicating congestion related data loss, and
performing a re-transmission at a traffic source after receiving a predetermined number of duplicate acknowledgments with congestion notification information.

Description

FIELD OF THE INVENTION

The The present invention relates to a method for controlling an overload in a packet-switched network, in particular a wireless or mobile network using the Transmission Control Protocol (TCP) or the transmission control protocol is used as a transport layer protocol, as well as such packet-switched telecommunications network.

BACKGROUND OF THE INVENTION

congestion control or overload defense is one of the key mechanisms to the increasing diversity of services and types of traffic in the Internet to accommodate. As is well known, TCP is the most popular Transport layer protocol for data transfer. It represents connection-oriented reliable Transfer data between two connection hosts ready, where a host a computer connected to a network or any System, which are connected to a network can connect to a different host connected to the same network services offer. TCP uses several techniques to maximize performance the connection through monitoring different, related variables. For example, TCP contains one internal algorithm to avoid overload.

Overload protection addresses the general problem of traffic management for packet-switched networks. overload indicates a situation where the number of transmission requests at a special time the transmission capacity at one (called "bottleneck resource") certain Network point exceeds. Overload leads more conventional Way to overload conditions. When a result can for example, the latches overflow so that packets either through the network or retransmitted by the subscriber. In general creates overload, if the incoming traffic is on a particular connection path is larger as the capacity the outgoing connection path. The primary function of the overload control or overload protection This is good throughput and delay performance ensure while a fair allocation of network resources to the users is respected. For TCP traffic, whose traffic patterns are often very bursty or a varying number of packets per unit of time can, Link control is a challenging problem. It is known that packet losses cause a noticeable deterioration at TCP throughput. Therefore, should for the best possible Throughput a minimum number of packet losses occur.

So far have been several schemas, including fast TCPs and fast TCP respectively presented to the function of preventing overload in the TCP flow control. Although the purpose of this Mechanisms consists of packet loss or discard of packets in the case of queue overflows can avoid a network congestion not completely be avoided, even with extremely perfect overload prevention mechanisms. Thus, it is still necessary to use these mechanisms with existing ones TCP flow control mechanisms for overload control or overload protection to combine, that is, Source Window Reduction or Source Window Reduction should sometimes being called by lost packets due to a cache overflow, thereby the temporal overload mitigate.

Was initially intends that the Internet Service Provider's best effort supports so-called best-effort services, and the TCP overload control method, which actually was implemented, was designed on the assumption that the network would be treated as a "black box" is called, that the end nodes do not perform any control by themselves directly from the state of routers and transmission lines make sure but rather regulate the traffic by indirectly from packet losses and response time fluctuations conclusions on pull the network load. For wired networks, this must not cause serious problems because packet losses are essentially due to overload occur. In the presence of high error rates and intermittent Connection characteristics as with wireless connection paths, conditional this reliance on packet losses as an indicator of congestion but a considerable one Deterioration of TCP performance, since the TCP on packet loss reacts as it does in the wired or wired environment would react. The is called, it leaves its window size for retransmission decrease or decrease before retransmitting packets, initiating congestion control (or congestion avoidance) or prevention mechanisms and sets its timer for retransmission back. this leads to to an unnecessary Reducing the connection bandwidth usage of wireless and Mobile networks, resulting in low throughput and very high interactive delays conditionally.

Recently, several schemes have been proposed to overcome the effects of lossless congestion on TCP performance Mitigate networks that have high loss wireless or similar connections.

In the article "Implementation and Performance Evaluation of Indirect TCP "by Ajay V. Bakre et al., IEEE Transactions on Computers, Volume 46, No. 3, March In 1997, the indirect TCP protocol is considered one of the first protocols described to distinguish between different losses, by making a TCP connection between a fixed and a mobile Host split into two separate connections at the base station so that is a more optimized wireless connection-specific Protocol, which is tuned for better performance is over a one-step wireless connection or one-hop wireless connection can be used. However there are There are some disadvantages with this approach, such as loss the semantics, application feedback or "Application Re-linking "and software administration data or software overhead.

Farther was an ELN protocol (Explicit Loss Notification or explicit Loss notification), where an option to express Notification about a loss on TCP acknowledgments added is when a packet is lost on a wireless connection path. In this case, need future cumulative confirmations, which correspond to every lost parcel, always be marked to to identify that a loss has occurred that is not overloaded Has. Furthermore could it may be difficult to identify packages due to errors lost on lossy links, and one Connection of a corrupted Packet because the header or header itself will be corrupted could.

In addition is another research area 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, at the overload control is decoupled from packet losses. Because of this, packet losses no overload control call or activate, so that transmission errors are not too lead to a reduced throughput. In particular, an express Notification regarding an overload or Explicit Congestion Notification (ECN) for a TCP confirmation option added by overloading in the network is detected. Upon receipt of this ECN message, decreased the sender will be overload window ("Congestion Window") every time a loss occurs.

however have many current networks with routers whose main function is to route packets, no provision for capture an incipient overload, before a queue overflow occurs. Even if such arrangements were made, regardless of this the packet mark rate does not keep pace with their pass rate while Periods in which the average queue size exceeds an upper threshold. As a result, routers lose packets rather than rejecting them Set ECN in the packet header.

In spite of Of all these difficulties, it is likely that ECN will be used gradually becomes. It is thus an essential requirement for future TCP Networks that they are for the conversion are designed.

Another Prior art in the relevant This field is known from the following references, however Old not mentioned request for a migration of TCP networks for the Use of ECN can.

In the article "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links "by H. Balakrishnan et al., IEEE / ACM Transactions on Networking, Vol. 6th of December 1997, pages 756 to 769, it is generally about a loss control in a TCP network. He especially teaches the addition of Loss notifications that indicate a loss that not with an overload related. He also teaches the addition of ELN information to TCP acknowledgments. Also This article teaches that a packet is on the wireless link between two nodes has been lost. Therefore, there is not a cache overflow the cause of packet data loss as discussed above.

In the article "Improving TCP / IP Performance over Wireless Networks "by H. Balakrishnan et al., MOBICOM 95, Berkeley, USA, 1995, pages 2 to 11, becomes essentially one Caching packets at a base station and performing local retransmissions taught.

In the article "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer "by K. K. Ramakrishnen and R. Jain, Proc. SIGCOMM, 88, Vol. 18, no. 4, August 1988, it is taught that an overload hint bit is placed in a forward-looking packet in question. Farther is indeed a dependency taught from a middle queue length but without up to refer to the loss of a data packet. This article contains no Reference to an appropriate realization a retransmission in this context.

In US Pat. US 5,675,742 A is be wrote that for a feedback process due to congestion in a router, a flag is set in a packet and transmitted to the target system. However, this document does not contain any helpful indication of a suitable realization of a retransmission in this context.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention, a method for controlling the overload in a packet switched network and a packet switched telecommunication network by means of which there is an unnecessary reduction in the link bandwidth usage can be prevented.

These The object is achieved by a method according to claim 1, and by a packet-switched telecommunications network according to claim 13th

advantageous Further developments and modifications are specified in the respective dependent claims.

Accordingly, a abbreviated ECN mechanism or short-cut ECN mechanism (wireless ECN or Wireless ECN), preferably in wireless or Mobile environments can be used. Like ELN, the mechanism is adapted to the TCP source the reason for to report a packet loss. In particular, the source can be informed be that a loss has occurred due to reasons associated with Network congestion related, so that overload control from retransmissions can be decoupled. Thus, the congestion window is only reduced if the congestion notification information was received without taking account of packet losses. By fast Inform the source about the occurrence of a loss due to reasons relating to one Network congestion can stand, overload control and loss recovery mechanism. This mechanism is easy to implement and with the existing TCP congestion control or overload protection compatible.

If Wireless ECN or wireless ECN used in the conventional ECN environment Wireless ECN becomes a new instance through the TCP source the overload interpreted. The integration of wireless ECN in the well-known ECN mechanism allows the overload control by WECN or ECN messages is initiated. As a WECN message at least not later as the threshold number of subsequent packets are added should, it can overload control even earlier than call with the fast mechanism for retransmission. The integration from WECN to the ECN mechanism not only avoids unnecessary congestion-induced packet losses, but also prevents unnecessary delayed initiation of overload control, which often occurs due to a loss of an ECN package or an inefficient effect of the ECN mechanism or other exceptions in the ECN mechanism.

Preferably the following data packet follows directly the lost data packet. This ensures that the congestion notification information is unavoidable added can be, even with or at multiple packet losses, and it there is no need for one Mechanism in the router to monitor the average queue size. Since the congestion notification information as quickly as possible after the packet loss due to congestion has occurred added ensures that network congestion is mitigated over time.

Farther can the overload notification be added in the header of the following data packet. In this case, for example, bit # 5 may be used in the IPv4 TOS octet become.

Preferably should any of the network nodes be allowed the congestion notification information add, thereby an overload-related Display data loss. This will make multiple WECN messages a robustness against the possibility the loss of a WECN packet in the bidirectional transmission paths ready.

The Add the congestion notification information is allowed to those subsequent data packets leading to the same congestion window in the successive past Routers belong. In addition, each network node is allowed the congestion information only once add. Thus belongs any congestion notification information, in a transmission window added was, to another network node.

Upon receipt of a data packet with 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 # 8 in the TCP header of the subsequent acknowledgment packet. Because TCP uses the WECN message to raise congestion control In the case of packet loss, a retransmission mechanism is performed without a WECN message. Thus, the TCP data flow rate is not affected. This is extremely useful in wireless or mobile networks because the network itself has the function of distinguishing different causes of packet loss. By notifying the source with a WECN acknowledgment packet whenever a congestion-related loss has occurred, packet losses due to transmission errors can not decrease the TCP flow control window (congestion window), resulting in a significant improvement in performance. The congestion window can only be reduced by the congestion notification flag set due to a congestion loss.

Preferably becomes an overload processing at the traffic source only repeated after the outstanding Data packets that transmit before the first receipt of a congestion notification flag were all confirmed were. As a result, the reduction of the congestion window is not repeated, if the packet was lost before the source responds to its window the congestion notification flag has decreased.

Of the WECN mechanism according to the present Invention allows the whole Decoupling the overload control function of packet losses. Compared with ECN, the WECN notification can inevitably added because the lost packets give time to the cache, to clear some space for holding and transferring new data. If a WECN is lost, for example, in a state of a communication path high loss, where all WECN messages in a control cycle lost, or in a case where only one WECN in a transmission window added and this WECN is lost due to a malfunction, this becomes Loss to a failure of the overload control For this River and increased overload lead the network, because the assumed cause of the data loss is no overload was. Regardless, other WECNs for subsequently lost packages in the next congestion window added. Thus, the mechanism is very safe and robust compared to the ECN mechanism where the loss of one ECN no other addition of one ECN packages.

According to the present In the invention, no packet losses need to be taken into account to overcome congestion window degradation call. Because mechanisms for monitoring the mean queue size in the Routers are not required, the WECN mechanism can work on a be implemented in a simple way and opens the way to another Use of the ECN mechanism. It should be noted that the WECN mechanism is compatible with all TCP congestion control mechanisms, as long as they are called by packet losses, and it's easy to bring these into wireless and mobile networks. With the incremental or gradual deployment of the ECN mechanism, it can be integration from WECN in ECN allow the overload control by WECN or ECN messages and WECN package functions only too initiate, if within the corresponding data window Packet loss due to overload earlier arrives as an ECN. With the addition of WECN to the Fast-TCP mechanism could the window reduction or window reduction is called by WECN when a cache overflow occurs because of the TCP behavior at the end systems is not changed. Thus, this is an effective way to improve TCP performance in wireless and mobile networks.

There it is necessary to WECN no later than after a threshold number of duplicate confirmations add, can additionally an improved TCP performance expected in wired network environments, since the initiation the overload control is accelerated by the WECN message. If this message to trigger the transmission or retransmission of It can also increase the speed of the Entry into the TCP recovery phase or TCP recovery phase due to overload speed up, so that overloading quickly transfer lost packets again become.

BRIEF DESCRIPTION OF THE DRAWING

following The present invention will be explained in more detail on the basis of a preferred embodiment with reference to the attached drawing described. Show it:

1 a general block diagram of a flow control loop in a TCP over ATM network to which the preferred embodiment of the present invention is implemented;

2 a general block diagram of an intermediate node, which is arranged between a traffic source and a traffic destination, according to the preferred embodiment of the present invention;

3 a general block diagram of two successive intermediate nodes according to the preferred embodiment of the present invention;

4 a diagram of transmissions between a traffic source and a traffic destination in the event that a wireless congestion notification (WECN) arrives at the traffic source before a conventional congestion notification (ECN) arrives within the same transmission window;

5 a diagram of transmissions between the traffic source and the traffic destination, if a non-congestion packet loss is detected before a congestion notification within the same transmission window;

6 a diagram of transmissions between the traffic source and the traffic destination, in the case that a WECN arrives at the traffic source after an ineffective ECN implementation in the previous transmission window;

7 a diagram of transmissions between the traffic source and the traffic destination, in the case that a WECN is received at the traffic source after a normal ECN within the same transmission window;

8th a diagram of transmissions between the traffic source and the traffic destination, in the case that a WECN before three consecutive packets in the same transmission window is set;

9 a diagram of transmissions between the traffic source and the traffic destination, in the case of a WECN and a non-congestion packet loss within the same transmission window; and

10 a diagram of transmissions between the traffic source and the traffic destination, in the case of a delayed setting of the WECN and multiple congestion losses within the same transmission window.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Hereinafter, the preferred embodiment of the present invention will be described based on a TCP over-ATM network as in FIG 1 shown.

ATM (Asynchronous Transfer Mode) is a connection-oriented packet switching technique, that of the international telecommunications standardization organization ITU-T as the target solution the broadband digital network for integrated services or Integrated Services Digital Network (B-ISDN) was selected. The problems of conventional Packet networks were switched to the ATM Network by using short packets of a standard length (53 Bytes), known as cells, are eliminated. ATM networks fast as backbones for the numerous parts of TCP / IP networks such as the Internet used. This also applies to wireless or mobile networks.

According to 1 For example, a connection between two user terminals A and B is shown in the TCP over ATM network, that is, the user terminals use TCP as a transport layer protocol. In addition, two access nodes AN1 and AN2 of the user terminals, an intermediate node N1 and transmission lines TL1, TL2 connecting the nodes are shown.

After this an initial one Handshake is completed, the begin user terminals A and B with sending data using TCP segments. The term "segment" refers to that of TCP to IP (Internet Protocol) directed information unit. IP Headers or IP headers are added to these TCP segments to get IP To form datagrams, that is, TCP segments are within IP datagrams as those of IP used information units transferred to the receiver. Every true TCP segment, which contains the handshaking segments is confirmed. To the Illustrating the function of the flow control loop is assumed that the user terminal A sends a TCP segment to the user terminal B. At the network layer, the user terminal A adds a Add IP header to this TCP segment to form an IP datagram. This Datagram will be in standard ATM cells in the access node AN1, which is at the edge of the ATM network ANW is arranged. The cells of the datagram are then passed through the ATM network is routed to the access node AN2 of the user terminal B. This access node reconstructs the original IP datagram from the incoming cells and sends the IP datagram to the user terminal B. The user terminal B removes the IP header to expose the TCP segment. If that Segment is received correctly, the user terminal B sends confirming TCP Segment ACK back to the user terminal A.

TCP is one of the few transport protocols that originally used an overload control mechanism Has. The preferred embodiment The present invention is based on this known TCP control mechanism.

Therefore this mechanism will be briefly described below.

TCP congestion control is based on two variables: the offered window of the recipient (Wrcvr) and the overload window (CNWD). That of the receiver offered windows is maintained at the receiver as a measure of the buffer capacity of the receiver, and the overload window is at the transmitter as a measure of capacity led the network. The TCP source can never send more segments than the minimum of the offered window of the recipient and the overload window.

The TCP overload control method points two phases: slow start and overload prevention. One as SSTHRES (Slow Start Threshold) Variable is kept at source, to distinguish between the two phases. The source begins to send in the phase of slow start by adding a TCP segment is sent, that is, the value of CWND is initially set to one. If the source a confirmation receives, it raises CWND at one, sending two more segments as a result. To this Way, the value of CWND doubles after each round trip time during the Phase of slow start as each segment is acknowledged by the destination terminal. The slow start phase ends and the overload prevention phase begins when CWND reaches the value of SSTHRES.

If If a data packet is lost on a TCP connection, it receives the Source no confirmation and leads a loss recovery operation.

By Duplicate confirmations The TCP source can be made to reduce its output rate. This is based on the algorithms of fast retransmission and fast restore, which the source performs automatically after a certain number of duplicate confirmations were received. These algorithms are widely used in different TCP versions implemented. According to the algorithms leads the Source, after having a predetermined threshold number of acknowledgments (eg: three confirmations) has received a retransmission of which, by what the missing segment seems to be, without up the expiration of a timer for the retransmission to wait (fast retransmission algorithm) Algorithm). After that, leads the source overload prevention by, rather than a slow start, the data flow is not abrupt to reduce (algorithm of fast recovery or Fast recovery algorithm).

2 Figure 12 shows a general diagram of an intermediate node connected to a TCP source A and a TCP destination B, which may each be workstations or the like. In the intermediate node, an overload is represented as a black star, a continuous data packet as a solid square, and a data packet lost due to the overload as a dotted square.

According to the preferred embodiment According to the present invention, in the intermediate node is a wireless ECN (WECN) control device C, which is adapted a data packet with an explicit wireless overload notification (WECN or Wireless Explicit Congestion Notification) immediately after a packet loss occurred due to a cache overflow is to mark, wherein the buffer overflow by means of a (not shown) detection device can be detected. The detection device may be included in the controller C or may be in the intermediate node be a separate device.

If a first lost packet due to a cache overflow in the intermediate node or router within a transmission window If the TCP source is detected, a WECN will be in the header of the immediately following scrolling packet. The required time for this process is available due to of the lost data packet, resulting in additional cache time results. Thus, the WECK will be as fast as possible after a packet loss added so the network overload as soon as possible attenuated can be.

Furthermore, an arrow at the foot or lower end of 2 the transmission link of the WECN, wherein the TCP destination B sets a WECN flag in the header of a packet in response to the receipt of a WECN data packet, thereby notifying the congestion in the intermediate node.

Each node in the network should be able to add the WECN, thereby indicating congestion as packet loss occurs. To reduce redundant addition of WECN, all that is required is for a WECN message to be set in a node, which is sufficient to communicate the overload. However, the WECN, which may be a single WECN bit, may be added in the subsequent packets belonging to the same transmission or congestion window by different ones of the successive routers through which the data packets pass. Since it requires a round trip time from the first added WECN to reach the source A, and the state and buffer occupancy in each network node conventionally vary widely, generally not only one WECN in a transmission window is set during a round trip time since the first lost packet in each Intermediate node does not have to occur at the same time. Thus, each WECN added in a transmission window belongs to a different transmission network node, which is allowed to add the WECN only once.

3 shows a general diagram of an intermediate node 1 and an intermediate node 2, which are connected successively in the direction of the forward link. In the present case, both intermediate nodes 1 and 2 are overloaded or clogged. A WECN data packet with an added WECN is shown as a hatched square.

According to 3 A controller C1 located in the intermediate node 1 adds a WECN to the second data packet because the first data packet was lost due to congestion. Furthermore, the third data packet is lost due to the overload. However, since 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 over the forward link to the intermediate node 2, where the fifth and sixth data packets are lost due to the overload. Accordingly, a WECN is added to the seventh data packet by a controller C2 of the intermediate node 2.

The TCP destination B receives the data packet sequence comprising WECN packets number 2 and 7, and sets the WECN flags of the corresponding acknowledgment packets to the TCP Source A returned to become.

On the forward link allowed to consecutive routers do not use a WECN bit in incoming packets Clear or overwrite, thereby maintaining the WECN rule compliance in the network. There the TCP destination B a WECN flag in the TCP header of an acknowledgment packet in response to each IP packet with an added WECN Bit sets, the TCP source A within an overload window receive a variety of WECN packets from different Intermediate node originate. Since the main function of the WECN is to only once within a transmission window in the Case of network congestion an overload control to initiate, that is, the overload window To reduce this multiple WECN news also cater for a stability against the possibility Losing a WECN packet on the bidirectional link.

Around the currently proposed ECN mechanism in the IETF draft or IETF Draft, should be an overload exposed information in the regular headers of an IP packet be preserved because the processing of regular headers in IP packets is more efficient than processing the header information in IP options. With the ECN mechanism, bit # 6 and bit # 7 of the IPv4 TOS octet as the ECT bit or the CE bit. additionally to do this, bit # 5 in the IPv4 TOS octet can be selected as the WECN echo flag, which is used to overload packet losses through intermediate router or other network elements. This can be a different Window reduction initiated by the WECN overload control become.

If Therefore, if the TCP destination B receives a CE packet, it sets the ECN echo flag in the TCP header of the subsequent ACK packet. According to the different ones CE bit settings for the ECN and WECN packages are two different flags of the TCP headers required. Since bit # 9 is the ECN echo flag of the TCP header is determined, bit # 8 may be the WECN echo flag be used. If any of the received data packets CE packets are set bit 5, thus has the returned ACK set its WECN echo flag. If any of the received Data packets are CE packets with bit 7 set, then has the returned ACK set its ECN echo flag. Because only one WECN in an intermediate node added The number of WECN packets will be the number of total Do not exceed network node, to go through the data packet. This can be the load providing an interphase system device between IPs and TCP on the landing page.

Thus, since non-congestion packet loss is not allowed to initiate congestion control, according to the WECN mechanism proposed above, in terms of the consideration of decoupling the congestion control and retransmission strategies, end nodes detect lost data packets by receiving a WECN message through the interim Network nodes have just been set at times of cache overflow, wherein the overload response of the end nodes to a received CE packet is at least as strong as the overload response to a lost data packet which is independent of the overload control. There is also no need for special implementations of TCP in Referring to the ECN mechanism proposed by the IETF, where TCP requires a less conservative response compared to the case of a lost packet, especially over small time scales, since a buffer overflow has not yet occurred.

The additional Requirement for the TCP source A to respond to multiple WECN acknowledgment packets is that they do not repeat the reduction of the overload window should, since the package was probably lost before the TCP Source A her overload window in response to an earlier one WECN confirmation package has decreased. Thus, the TCP source A should point to a WECN acknowledgment packet at the most react once per round trip. This can be achieved by the TCP source A is adapted in such a way that it only respond to a subsequent WECN acknowledgment packet after the pending data packets that were transmitted before the TCP source A in a phase of loss recovery on the receipt of the first WECN confirmation package occurred, all confirmed were. Similar to could be at the ECN mechanism Changed TCP be a negotiation phase during setup or setup to determine if both end nodes are WECN enabled.

Of the WECN mechanism according to the preferred embodiment of the present invention to an independence of TCP from the packet loss as an indicator of congestion. There TCP uses the WECN message to invoke overload control, whenever a packet loss occurs, it becomes merely a mechanism for retransmission as an answer to a packet loss without a WECN message so the TCP dataflow rate does not start in such a case impaired is. This is very useful in wireless or Mobile networks, because the network itself has the function of distinguishing has different causes of packet loss. Thus, the TCP overload window can only be reduced by the WECN message, due to from overload losses is set or adjusted.

moreover TCP source A can only be used once during a round trip, and generally the earliest of the received WECN and ECN ACKs. If first one ECN ACK is received, the conventional overload control at the TCP Source A is called. If some packet loss due to overload arrive in front of the ECN messages within a turnaround time bz. However, the WECN messages appear immediately the overload conditional first packet loss were added, arrive on time, around a general overload control to initiate, for example, with half reduction of the window size instead of waiting for the later Arrival of the ECN packages. Thus leads WECN to an overload control, the complete is free from non-overload lost parcels, and high performance is ensured without being forced to islands of different causes Resort to packet loss on wireless and mobile networks.

Of the WECN mechanism according to the preferred embodiment of the present invention not only to decouple overload control from loss recovery, but also contributes to the loss recovery phase. Since it is necessary that the WECN be immediately after the occurrence of the Packet loss is set, it is extremely likely that the WECN confirmation package arrives before the threshold number of duplicate acknowledgment packets. If This WECN message is used to transfer or retransmit To trigger any data packets, this may be the speed of entering the TCP recovery phase so lost packets with overload reference quickly retransmit. However, the ECN may not always be right after a lost one Package added if there are several consecutive packet losses or disorganized packets before the arrival of the ECN message. Consequently Can not judge which lost package the addition of the ECN has triggered, or whether she is lagging added has been. Thus, ECN is only suggested to apply quickly in the loss recovery phase before entering the threshold duplicate confirmation packets or the threshold number of duplicate acknowledgment packets arrive. Otherwise, should be data transfer while the loss restoration based on the conventional Algorithms of fast retransmission and fast recovery carried out become.

4 FIG. 12 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 represented as a plurality of forward and backward and forward arrows, of which FIG each indicates the transmission of a data packet or an acknowledgment packet (ACK). According to the diagram, the transmission proceeds from the upper end to the lower end and corresponding ACK messages are indicated by the backward arrows from the destination B to the source A.

Consequently is a transmission window by the time period (vertical direction) from the starting point of a forward arrow indicated to the endpoint of the corresponding backward arrow.

During the transfer the message X becomes the second data packet due to a congestion loss 1 lost to the TCP destination B on the following third Data packets is communicated. Thus, a confirmation packet with a set or set WECN echo flag returned to the TCP source A, before any ECN message has arrived. Based on the received confirmation and duplicated confirmation or duplicate confirmation with the set WECN echo flag, the TCP source A performs an overload control by reducing SSTHRES to half the current CWND value by. Then CWND is set equal to the new SSTHRES.

In In the present case, one ECN is delayed in the fifth data packet set, such that an ECN echo flag in the corresponding ACK Package is set. At TCP source A, the ACK with ECN echo flag ignored because the WECN ACK is already in the same transmission window (ie, forward and backward arrow related to the transmission the message Y) was received. Regardless, the conventional algorithm becomes for fast retransmission in TCP or the conventional TCP fast retransmission algorithm for the lost packet 1 started because the threshold number of duplicate ACKs, this means, 3 ACKs was received.

Farther occurs an additional overload loss 2 in the sixth data packet, such that a WECN in the seventh data packet is set to an ACK with a WECN echo flag to initiate. However, the WECN message is also sent to the TCP Source A is ignored because the ACK with WECN echo flag is also inside the same transmission window Will be received. Again, the conventional TCP fast retransmission algorithm for the lost packet 2 after receiving 3 duplicate ACKs performed.

5 shows a diagram similar to the diagram according to 4 in which a non-overload loss 1 occurs during the transmission of the first data packet of the message X. In the present case, the threshold number of duplicate acknowledgments arrives at the TCP source A before receiving the ECN acknowledgment. Furthermore, an overload loss 2 occurs during the transmission of the sixth data packet of the message X.

There in response to the non-overload loss 1 no WECN added becomes the conventional one Fast retransmission algorithm or algorithms performed for fast retransmission, the is called, the lost data packet is retransmitted after three duplicate acknowledgments were received. Furthermore, the conventional overload control, for example Reduction of SSTHRES to 0.625 CWND and setting a new CWND same as the new SSTHRES in response to receiving the ECN confirmation. at In the present example, a WECN will respond in response to the non-overload loss 2 set. However, the corresponding WECN ACK is ignored because within the same transmission window Will be received. Regardless, due to the conventional Algorithm for retransmission the lost packet 2 upon receipt of three duplicate acknowledgments retransmitted.

6 Fig. 14 shows another transmission example in which an ECN is set in a previous transmission window (message X) due to a detected overload, and regardless of the conventional overload performed in response to the reception of the ECN ACK, a subsequent packet loss occurs in the subsequent transmission window (message Y) ,

by virtue of the overload loss a WECN is set in the subsequent data packet, and a WECN overload control, this means, SSTHRES = 1/2 CWND and CWND = SSTHRES, according to the preferred embodiment of the present invention is operated in response to the reception of the WECN ACK performed. Furthermore, the conventional fast retransmission performed after receiving three duplicate confirmations, thereby losing the lost Resend the data packet. The next ECN message will be ignored due to their reception within the same transmission window.

7 FIG. 12 shows a transmission example in which an ECN message is received before a subsequent non-overload packet loss 1 and an overload packet loss 2 within the same transmission window.

According to 7 a conventional overload control is performed in response to the receipt of the ECN ACK. However, the non-overload loss 1 does not initiate a WECN message. After three duplicate ACKs, the conventional retransmission of the non-overload loss 1 is performed. The WECN ACK subsequently set in response to the Loss of Overload 2 is ignored on TCP Source A because it occurred in the same transmission window. Regardless, conventional retransmission is again performed upon receipt of three duplicate acknowledgments.

8th shows a case where the second and sixth data packets of a message X are lost due to congestion and the seventh data packet is a disordered or mismatched package. Thus, WECN messages are set in the third and eighth data packets since the seventh data packet is a disordered one. The overload 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 receiving three duplicate ACKs. However, the second WECN ACK, which is accompanied by a duplicate WECN ACK (due to the unordered packet), is ignored since it is received within the same transmission window. Regardless, again, the conventional retransmission is performed for the lost packet 2 after receiving three duplicate ACKs. Since the unordered package can not be identified, retransmission is not possible.

In 9 Fig. 12 shows another transmission example in which a non-congestion loss 1 (first data packet) and a consequent congestion loss 2 (fifth data packet) followed by a non-congestion loss 3 (sixth data packet) occur during the transmission of a message X.

Of the first non-overload loss 1 does not initiate any overload control procedure and leads to a conventional one retransmission after receiving three duplicate ACKs. Due to the immediately following Not overload loss is the one in the sixth data packet in response to the overload loss 2 received WECN not received at the TCP destination B. Because the sixth Data packet due to non-overload loss 3 is lost, no WECN is set in the seventh data packet. Thus, the WECN ACK will respond in response to receiving the eighth Transfer data packets to thereby the overload control procedure according to the preferred embodiment initiate the present invention. Because of the lost sixth and non-WECN seventh data packets, the WECN ACK is accompanied by two duplicate WECN ACKs. Thereafter, the losses 2 and 3 according to the conventional algorithm for retransmission retransmitted.

Finally shows 10 a case in which three overload losses 1 to 3 occur during the transmission of the message X, with the corresponding WECN being set delayed.

According to the conventional retransmission each of the three lost data packets 1 through 3 is passed through the TCP Retransmit source A in response to receiving the respective three duplicate ACKs (retransmission the lost packet 3 is not shown). In the present Case becomes the overload control procedure according to the preferred embodiment delayed by the present invention, until the first WECN ACK was received. However, the subsequent WECN ACK within the same transfer window ignored.

The above-described ECN-based overload control method can be used in any packet network. According to the above Description the overload control can be done without the conventional overload control processing to change the TCP significantly.

Even though the invention herein in connection with the preferred embodiment according to the attached drawing has been described, it is clear that the invention is not limited to this Examples limited because they vary in several ways within the scope of the appended claims can. As stated above, a prerequisite for a user terminal is that it received (that is, unadulterated) Data units confirmed correctly. Therefore, the idea can in principle be applied to any other protocol which confirmations sends. As already stated can the user terminals have wireless access to the network.

In summary The invention relates to a method for controlling or reducing the overload in a packet-switched network, in particular a mobile or Wireless network where the transmission control protocol Transmission Control Protocol (TCP) as the transport layer protocol is used. An overload notification information is added to a data packet, which is a data packet lost due to a cache overflow follows. This is an effective way to increase TCP performance in wireless and mobile networks, since overload control Completely independent of retransmissions carried out can be. The proposed mechanism provides a simple Way of introducing of TCP overload prevention control strategies in wireless and Mobile networks ready. In addition, should the overload notification information at least not later are added as a threshold number of subsequent packets, thereby speeding up the overload control initiation and to accelerate loss recovery due to overload set.

Claims (20)

A method of controlling congestion in a packet-switched network comprising traffic sources (A), traffic destinations (B) and network nodes (AN, N1) the transmission control protocol (TCP) is used as a transport layer protocol; and forwarding data packets and corresponding acknowledgments between a traffic source and a traffic destination, characterized in that said controlling comprises: adding, at a network node, congestion notification information to a data packet following a data packet lost due to a cache overflow, thereby indicating congestion related data loss, and performing a retransmission operation on a traffic source after receiving a predetermined number of duplicate acknowledgments with congestion notification information. The method of claim 1, wherein the following data packet follows the lost data packet directly. Method according to claim 1 or 2, wherein the overload notification information is added in the header of the following data packet. Method according to one of the preceding claims, wherein the overload notification information through each of the network nodes can be added to thereby an overload-related Display data loss. Method according to one of the preceding claims, wherein it is allowed the overload notification information through successive network nodes in subsequent data packets add, to the same overload window belong. Method according to one of the preceding claims, wherein it is allowed to each network node, the overload information only to add once. Method according to one of the preceding claims, wherein the traffic destination an overload notification flag in the header of a confirmation packet in response to a received data packet with added overload notification information puts. Method according to one of the preceding claims, wherein the added overload notification information Bit # 5 in the Service Type octet according to the Internet Protocol version 4 (IPv4 TOS octet). The method of claim 7, wherein the overload notification flag Bit # 8 in the Transfer Control Protocol (TCP) header the confirmation package is. Method according to one of the preceding claims, wherein an overload processing at the traffic source is repeated only after the outstanding Data packets that transmit before receiving the first congestion notification flag were all confirmed were. Method according to one of the preceding claims, wherein an overload window in response to the receipt of the overload notification flag is reduced. The method of claim 11, wherein the overload window is reduced only when the overload notification flag has been received before the arrival of a predetermined number of duplicate confirmations, related to the lost data packet. A packet-switched telecommunications network, comprising: Network nodes (AN1, AN2, N1) passing through transmission lines (TL1, TL2) are interconnected; and User terminals that are connected to the network nodes, wherein the user terminals as traffic sources (A) that transmit data packets, and operate as traffic destinations (B) that receive data packets, in which the transmission control protocol (TCP) is used in the network as a transport layer protocol becomes; characterized in that the network further comprises: detection devices for detecting a loss of a data packet due to a buffer overflow in one of the network nodes; and a control device (C), at the network node, for adding congestion notification information to a data packet which is due to the buffer overflow lost data packet follows, in response to a detection result the detector, thereby indicating congestion related data loss, and that adapted user terminals operating as traffic sources (A) are about to retransmit only to perform after a predetermined number of duplicate acknowledgments with overload notification information were received. Telecommunications network according to claim 13, wherein said detection means ( 10 ) are provided in at least one of the network nodes. Telecommunications network according to claim 13 or 14, wherein the control device (C) to is adapted to add the congestion notification information only once in a transmission window. Telecommunications network according to one of claims 13 to 15, where the traffic terminals (B) operating user terminals adapted are to an overload notification flag in the header of a confirmation packet in response to receiving a data packet with the added congestion notification information to put. Telecommunications network according to one of claims 13 to 16, the user terminals operating as traffic sources (A) being adapted, to overload control in response to the receipt of the congestion notification flag. A telecommunications network according to claim 17, wherein the overload control reducing an overload window includes. Telecommunications network according to one of claims 13 to 18, wherein the user terminals operating as traffic sources (A) are adapted, to a subsequent overload notification flag only to respond after pending data packets that transmit were before receiving into a loss recovery phase of the first overload notification flag was confirmed, all were. Telecommunications network according to one of claims 13 to 19, wherein the packet-switched network is a mobile or wireless network is.