Flow control in a telecommunications network

Flow control in a telecommunication network

FIELD OF THE INVENTION

The invention relates generally to flow control in a telecommunications network. More specifically, the invention relates to congestion control in a packet-switched telecommunication network, in particular in a network in which TCP (Transmission Control Protocol) is used as a transport layer protocol.

Background of the invention

As is well known, TCP is the most popular protocol used in the transport layer for data transmission. It provides reliable connected data transfer between two hosts. (A host refers to a networked computer or any system that can be connected to a network to provide services to another host connected to the same network.) TCP uses several procedures to maximize transport connection performance by monitoring various variables associated with the transport connection. TCP includes, for example, an internal algorithm to avoid congestion.

ATM (Asynchronous Transfer Mode), on the other hand, is a (newer) connected packet switching technology that has been chosen as the basic solution by the International Telecommunication Standardization Organization (ITU-T) as a basic solution for broadband digital multiservice network (B-ISDN). In the ATM network, the problems of traditional packet networks have been eliminated by using short, fixed-length (53 bytes) packets called cells. ATM networks are rapidly being adopted as backbone networks in various parts of TCP / IP networks (such as the Internet).

Although ATM is designed to provide an end-to-end transport layer service, it is very likely that in the future the networks will be implemented in such a way that (a) TCP / IP remains the de facto standard for networks and (b) only part of the end-to-end connection is implemented with ATM . Thus, although ATM will continue to be utilized, TCP will still be needed to provide end-to-end transmission services.

The introduction of ATM also means that implementations must be able to support a large number of existing data applications in which TCP is commonly used as a transport layer protocol. In the past, several approaches have been developed for managing congestion in ATM networks to transfer existing upper layer protocols to ATM networks.

Congestion control is related to the general problem of packet network traffic management. Congestion refers to the situation where the number of transfer requests at a given point in time exceeds the capacity of a certain point in the network (called a bottleneck resource). Congestion usually leads to an overload situation. As a result, for example, buffers overflow, causing either the network or the subscriber to retransmit packets. In general, congestion occurs when the amount of traffic coming to a particular link exceeds the link's capacity. The main function of congestion control is to ensure good performance in terms of throughput and latency while maintaining a fair distribution of network resources to users. For TCP traffic, whose traffic patterns are often bursty, congestion control poses a challenging problem. It is known that packet loss leads to a significant decrease in TCP throughput. Therefore, for best throughput, the number of packets lost should be kept to a minimum.

The present invention relates to congestion management in packet networks. For the reasons mentioned above, most such networks are, and will be in the foreseeable future, TCP networks or TCP / ATM networks (i.e., networks where TCP provides end-to-end transmission services and ATM provides the “bit tubes” below). The following is a brief description of the congestion control mechanisms of these networks.

The ATM Forum has defined five different service categories that link traffic characteristics and quality of service (QoS) requirements to network behavior. These service categories are: Constant Bit Rate (CBR), Real-time Variable Bit Rate (rt-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). ). These service categories divide traffic into guaranteed traffic and the so-called “Best effort traffic, which is the traffic that fills the remaining bandwidth after the service has been provided to the guaranteed traffic.

One possible solution for “best effort” traffic is to use ABR flow control. The main idea in ABR flow control is to use special cells, the so-called RM cells (Resource Management) to adjust source rates. ABR sources regularly sense network status (factors such as available bandwidth, congestion status, and approaching congestion) by sending RM cells among data cells. RM cells are inverted back at the destination and sent back to the source. Along the way, ATM switches can write congestion information to these RM cells. Upon receiving the returned RM cells, the source may increase or decrease its rate or maintain its current rate, depending on the information provided by the cells.

In TCP / ATM networks, the source and destination are connected via an IP / ATM / IP subnet. Figure 1 illustrates the connection between TCP source A and TCP destination B in a network where the connection route passes through an ATM network using ABR flow control. When congestion is detected in the ATM network, the ABR rate control starts to act, forcing the edge router R1 to reduce its transmission rate in the direction of the ATM network. The purpose of the ABR monitoring loop is thus to command the ATM sources in the network to reduce its transmission rate. If the congestion is not relieved, the router's buffer will reach its maximum capacity. As a result, the router begins to reject packets, which results in a reduction in the TCP congestion window (the concept of congestion is explained in more detail below.)

In terms of congestion control, the network of Figure 1 comprises two independent monitoring loops: an ABR monitoring loop and a TCP monitoring loop. However, such congestion management, which is based on two congestion management systems on different protocol layers, can have an unexpected and undesirable effect on network performance. More specifically, the inner monitoring loop (ABR loop) can cause unexpected delays in the outer monitoring loop (TC P loop).

An alternative approach for best effort traffic is to use the UBR service with sufficiently large buffers and allow upper layer protocols such as TCP to handle congestion or congestion. Figure 2 illustrates such a network, i.e. a TCP / UBR network. Nodes in such a network comprise packet discard mechanisms that discard packets or cells when congestion occurs. When a packet is discarded somewhere on the network, the corresponding TCP source does not receive an acknowledgment. As a result, the TCP source reduces its transmission rate.

The UBR service does not use flow control and does not provide numerical guarantees for service quality; because of this, it is also the cheapest service to offer. However, due to its simplicity, a UBR alone without sufficient buffer size provides poor performance in congested networks.

To overcome this drawback, more complex congestion control mechanisms have been proposed. One such is the EPD (early packet discard) system. In an EPD system, an ATM switch destroys entire packets before a buffer overflow. In this way, the throughput of the TCP / ATM network can be significantly improved, since ATM switches do not have to send the cells of a packet containing corrupt cells, i.e. cells belonging to packets of which at least one cell has been discarded (these packets would be discarded in any case). Another advantage of an EPD system is that it is relatively inexpensive to implement in an ATM switch. Those interested in the subject will find a detailed description of the EPD method, e.g., in A. Romanow and S. Floyd, Dynamics of TCP Traffic over ATM Networks, Proc. ACM SIGCOMM '94, pp. 79-88, August 1994.

However, the EPD method treats users unfairly. This is because the EPD destroys entire packets from all connections, regardless of their current speeds or their relative shares in the buffer, i.e., without considering their relative impact on the congestion situation. To remedy this shortcoming, several variations have been proposed for the selective rejection of packets. One of these is described in Röhit Goyal, Performance of TCP / IP over UBR +, ATM_Forum / 961269. This method uses a FIFO buffer in the switch and performs virtual connection-specific accounting to keep track of the share of each virtual connection in the buffer. In this way, only cells in overloaded connections can be discarded, while underloaded connections can increase their throughput.

Despite all the improvements described above, the prior art congestion monitoring methods still have the disadvantage that it is not possible to give an early warning to the traffic source when excessive congestion is detected in the network. In other words, the traffic source is not quickly informed of congestion so that the source can reduce its transmission rate.

Brief Summary of the Invention

The object of the invention is to eliminate the above-mentioned drawback and to create a method which makes it possible, using a simple implementation, to inform a traffic source at a very early stage that the network is becoming congested and to ask the source to reduce its transmission speed. It is also intended that the method allows for efficient interoperability of TCP and ATM flow control mechanisms.

This goal can be achieved by using the solution presented in the independent claims.

The basic idea of ​​the invention is to delay the acknowledgments that are being transmitted from the destination to the sender. This can be done at the same point in the network where congestion is detected or alternatively the point in the network that detects congestion or congestion can direct another point in the network to delay acknowledgments. Thus, in the invention, congestion control is performed on the return route of the connection, while known systems control traffic on the forward route. Instead of discarding packets or cells on the forward route, the network of the invention delays acknowledgments on the return route and thus causes the TCP source to reduce its transmission rate.

The invention provides an inexpensive solution for providing an early warning to a TCP source that an overload or congestion is threatening the network. It is also important to note that there is no need to change the TCP protocol in any way. In order to implement the invention, a congestion control algorithm must be introduced into the network, but many existing algorithms related to TCP / UBR networks can be used for this purpose with only minor modifications.

In addition, the present invention can smooth the output rate of a TCP source, which in turn results in more efficient utilization of bandwidth. In addition, the buffer capacity requirements decrease as the amount of (speed) variation decreases.

According to a preferred embodiment of the invention, the load level information is transmitted from a point in the ATM network in the RM cells to a node providing a connection to the ATM network and acknowledgments are delayed in said access node based on the information contained in the RM cells. In this way, TCP and ATM flow control mechanisms can be made interdependent so that they work together effectively.

By means of the invention, the performance of the connections can be significantly improved, especially in large delayed networks.

List of figures

Figure 1 illustrates a TCP connection route through an ABR-based ATM subnet, Figure 2 illustrates a TCP connection route through a UBR-based ATM subnet, Figure 3 illustrates a flow control loop according to the invention in a TCP / ATM network, Figure 4a illustrates a new method In the IP switch, Fig. 4b is a timing diagram showing significant time points in the implementation of Fig. 4a, Fig. 5 is a flow chart, illustrating a method for determining delay values, Fig. 6a illustrates another possible implementation of acknowledging delay in a switch, Fig. 6b illustrates an alternative use of acknowledgment buffers, Fig. 7a illustrates an embodiment of the method in an ATM network, Fig. Fig. 8b illustrates another embodiment of the method in an ATM network, Fig. 9 illustrates the interaction of TCP and ATM flow control loops according to a preferred embodiment of the invention, Fig. 10 illustrates an example of packet transmission between a traffic source and a destination in a known TCP network, and Fig. 11 illustrates an example and a destination in a TCP network using the method of the invention.

Detailed description of the invention

Figure 3 illustrates the basic principle of the invention by showing the connection between two user terminals (A and B) in a TCP / ATM network, where the terminals use TCP as a transport layer protocol. In addition to the access nodes (AN1 and AN2) of the terminals, only one intermediate node (N1) and the transmission lines connecting the nodes (TL1 and TL2) are shown in the figure.

The connection between hosts A and B, like any other TCP connection, begins with a negotiation between the hosts to open the connection. The initial negotiation is called a three-stage handshake because during this handshake phase, three opening segments are moved. The term “segment” refers to an information unit transmitted by TCP to IP (Internet Protocol). The IP headers are combined with these TCP segments to form IP data telegrams, i.e. the TCP segments are transferred to the receiver within the IP data telegrams, which are the data units used by the IP. During the initial handshake process, the hosts inform each other, e.g., about the largest segment size they accept. This is done to avoid fragmentation of TCP segments, as it would significantly degrade the performance of the TCP connection.

After the initial handshake is complete, the hosts begin sending data using TCP segments. Each error-free TCP segment is acknowledged, including the handshake segments. To illustrate the basic idea of ​​the invention, suppose that host A sends one TCP segment to host B. At the network layer, host A adds an IP header to this TCP segment to form an IP telegram. The data telegram is converted to standard ATM cells at the access node AN1 located at the edge of the ATM network ANW. The telegram cells are then routed through the ATM network to the access node AN2 of the host B. This access node reconstructs the original IP datagram from the incoming cells and sends it to host B. Host B removes the IP header to expose the TCP segment. If the segment is received correctly, host B sends the acknowledging TCP segment ACK1 back to host A. Until now, the network has operated in a known manner.

The network load is monitored at the access node AN1, e.g., by monitoring the occupancy rate of one or more buffers that buffer traffic to the ATM network. If an overload is detected, i.e. if the buffer filling level exceeds a predetermined limit, a congestion notification CM is sent inside the node to delay the acknowledgments that are currently passing through the switch towards the traffic sources. Thus, the acknowledgment (ACK1) we use as an example is also delayed when it passes through the access node AN1, provided that there is an overload in the node AN1 just during that period.

TCP is one of the few transport protocols that has an internal congestion control mechanism. The solution according to the invention depends on this known TCP control mechanism, no other control mechanisms are needed at the source or destination. This mechanism is briefly described below.

TCP congestion control is based on two variables: the receiver's declared window (Wrcvr) and the congestion window (CNWD). The advertised window of the receiver is maintained at the receiver as a measure of the buffering capacity of the receiver and the congestion window is maintained at the transmitting end as a measure of the capacity of the network. A TCP source can never send more segments than the minimum from the receiver's indicated window and congestion window.

The TCP congestion control method consists of two steps: slow start and congestion avoidance. The variable SSTHRES (slow start threshold) is maintained at the source to distinguish between the two phases. The source starts transmitting according to the slow start by transmitting one TCP segment, i.e. the value of the CWND is set to one at the beginning. When the source receives the acknowledgment, it increments the CWND by one and as a result transmits two segments. In this way, the value of the CWND is doubled during the slow start phase during each period corresponding to the round trip time, because the target terminal acknowledges each segment. The slow start phase ends and the congestion prevention phase begins when the CWND reaches the value of the variable SSTHRES.

If the packet is lost over a TCP connection, the source does not receive an acknowledgment and its timeout is triggered. The source sets the variable SSTHRES to a value that is half the value of the variable CWND at the time of packet loss. More specifically, SSTHRES is set to max {2, min (CWND / 2, Wrcvr}} and CWND is set to 1. As a result, the source enters a congestion avoidance phase during which it increments CWND by 1 / CWND each time the segment is acknowledged.

Since the invention does not in any way alter the known TCP congestion control mechanisms described above, it will not be described in more detail in this context. Those interested can find more detailed information in several books in the field. (See, e.g., W. Richard Stevens, TCP / IP Illustrated Volume 1, The Protocols, Addison-Wesley, 1994, ISBN 0-201-63346-9).

According to the invention, one or more acknowledgments are delayed when congestion or congestion is detected at a network point. In this way, a TCP source operating as described above will automatically begin to reduce its transmission rate, or at least it will not increase its transmission rate as fast as it would otherwise increase. This is because the delay reduces the rate at which the source increases the size of its congestion window.

Figure 4a illustrates this principle by showing an example in which acknowledgments are delayed at the output port OP of the IP switch. The load measurement unit LMU measures the load level of the switch by measuring the degrees of filling of the buffers104602 that buffer the traffic going through the switch.

It should be noted, however, that the load level can be determined in any known manner.

IP data telegrams that pass through the switch in the reverse direction are first routed to the correct output port. The data telegrams received at this port are stored in the FIFO type output buffer OB.

The traffic splitter TS reads the stored buffers from the output buffer, packet by packet from the first memory location of the buffer ML1. The traffic splitter works as follows.

If the congestion signal CS from the load measurement unit indicates that the switch load is below a predetermined level, the traffic branch transmits all data telegrams (packets) directly to the outgoing transmission link OL, whether or not they contain acknowledgments.

On the other hand, if the congestion signal CS indicates that the load level has reached a predetermined level, the traffic branch starts reading the acknowledgment bit of the TCP header inside each IP datagram. If this bit is valid, i.e. if the telegram contains an acknowledgment, the traffic splitter forwards the packet to the acknowledgment buffer AB. If the bit is not valid, the traffic splitter forwards the packet directly to the outgoing transmission link OL. Therefore, only packets containing an acknowledgment are delayed.

In the acknowledgment buffer, each data telegram is delayed by a certain period of time. The length of the period is preferably directly proportional to the current load level measured by the LMU of the unit. When the delay time of each outgoing acknowledgment packet has elapsed, the packet is sent to the outgoing transmission connection.

If the ACKTi describes the time when the packet containing the acknowledgment is transferred from the traffic branch to the acknowledgment buffer and if the ACKTo describes the time when the packet is transferred from the acknowledgment buffer to the transmission link, the ACKTo can be represented as follows:

ACKTo (j) = ACKTi (j) + dj, j = 1,2, ...

where j is the packet sequence number and dj is the value of the delay associated with the packet having the sequence number j.

Figure 4b illustrates the moments when packets leave the traffic splitter and the acknowledgment buffer. Assume that an excessive load is detected shortly after ACKTo (7) (no acknowledgments have been delayed before this). If the congestion signal received by the delay control unit DCU indicates that the load level has exceeded a predetermined value, the delay control unit executes an algorithm that determines how long the next packet to be transmitted on the transmission link should be delayed. The calculated value may depend on one or more parameters, such as the current traffic speed, the current buffer load factor, or the previous value of the delay (dj.,). As can be seen in Figure 4b, the value of the delay may vary from one packet to another.

Fig. 5 is a flowchart illustrating an example of an algorithm performed by the delay control unit for each packet read out of the acknowledgment buffer AB.

If congestion is detected, the delay value d, of the packet currently being read from the acknowledgment buffer, (i.e. the time by which the current packet is delayed in the buffer) is calculated by the following formula:

dj = adj., + (1-a) d_M (1) where dj., Is the delay value of the previous packet, d_M is the measured delay value and a 15 is the smoothing factor (preferably a <0.5 <1). The measured delay is the actual delay measured from the moment the packet is received in the acknowledgment buffer until the moment the packet is read out of the acknowledgment buffer. This delay can be measured as an average over a certain period of time or as an average over a certain number of packets. The delay control unit can perform this measurement.

If congestion is detected and if dj., = O and d_M= 0, i.e. if the previous packet was not delayed and if there were no packets in the acknowledgment buffer AB during a certain predetermined previous period, the delay value dj of the current packet gets the value of the predetermined delay parameter d ^, i.e. dj = d_inifia|.

When the switch recovers from a congestion or overload condition, the delay control unit25 calculates the delay value dj using the formula:

dj = adj., - (1-a) d_M (2).

The purpose of the second term in formula (1) is to steadily increase the delay when congestion is detected, and in formula (2) to steadily reduce the delay when the network recovers from congestion.

Figure 6a shows the solution of Figure 4a in a shared buffer switch architecture. In the embodiment of Figure 6a, all packets are buffered in the shared buffer SB before each packet is routed to the right output port OPj of the switch. In another respect, the embodiment of Figure 6a corresponds to the embodiment of Figure 4a. The traffic splitters TS, (i = 1 ... n) can also form one unit that reads the packet one by one from the shared buffer and delivers the packet to the correct port. The delay control unit DCU (not shown in Fig. 6a) can also be implemented as a unit common to all output ports.

In the embodiments of Figures 4a and 6a, the acknowledgment buffer contains packets of multiple connections and all packets are delayed according to the same delay algorithm. Alternatively, packets can be stored on each output port on a connection-by-connection basis, i.e., data packets for each IP connection (or TCP connection) can be stored in a separate buffer. In these cases, each buffer may be a FIFO-type buffer because packets in a single queue do not need to be rearranged even if different connections are delayed differently. The relative share of each connection in the forward buffer can also be determined by load level measurement and the connections can be delayed based on the measured values. In this way, more acknowledgments can be delayed for connections that load the network more heavily. Figure 6b illustrates this alternative embodiment, in which the output port has a buffer unit BFU which contains separate queues for at least some of the connections.

If connection-specific buffers are not used and if different connections are delayed differently, the buffers may be, for example, shift register type memories that allow packets to be rearranged so that packets of less congested connections can bypass packets of congested connections.

As previously mentioned, the congestion monitoring method according to the invention can be utilized in packet networks. This means that the network has user terminals, network access points that connect to the network, and switches.

User terminals act as traffic sources, i.e. points that send and receive data. The switches can be packet switches or ATM switches. The access point can be, for example, a router or the access point can perform packet assembly / reassembly, routing or switching. Delaying the acknowledgment packets is preferably performed at the access points, but it can also be performed at the switches in the network, as will be described later.

Figures 7a and 7b show two different embodiments of the invention in an IP network. In the embodiment of Figure 7a, congestion detection and acknowledgment delay are performed at the interface switch IPS1, which provides the interface to the IP network. In the embodiment of Figure 7b, congestion detection is performed at the access node, while acknowledgment delay is implemented in the user terminal UT TCP / IP protocol stack. Congestion notifications CS are sent to the user's terminal, where packets containing acknowledgments are delayed as described above before being sent to the TCP source.

Figures 8a and 8b show two different embodiments of the invention in connection with an ATM network. In the embodiment of Figure 8a, congestion detection and acknowledgment delay 5 are performed at the access node AN. The access node can be divided into an interface card unit ICU and an ATM switch ASW. The interface card unit includes ATM Adaptation Layer (AAL) functions for splitting and reassembling IP data telegrams. Congestion is monitored in the ATM switch-side part of the node, e.g. by monitoring the filling levels of the buffers that pus10 the traffic from the subscriber to the network. Congestion notifications are forwarded to the interface card unit, where the reassembled IP packets are delayed as described above. In the implementation of Figure 8b, congestion is monitored at the switch ASW, acknowledgment packets are instead delayed in the TCP / IP protocol stack of the user terminal.

The implementations of Figures 7a and 8a are more advantageous because it is much more economical to implement acknowledgment delay in a single access node than in multiple terminals located in user premises. In addition, it is of course more advantageous that the users' terminals do not have to be modified in any way when the invention is implemented.

As previously mentioned, one network element on a connection route can command another network element on the same route to perform a delay. Figure 9 illustrates this principle in a TCP / ATM network by showing the connection between two terminals (A and B) using TCP as a transport layer protocol. In addition to the user terminal access nodes 25 (ANS and AND), only one intermediate ATM node (N1) and transmission lines connecting the nodes are shown in the figure. Assume that network nodes have channels in two directions; forward channel and reverse channel. To simplify the description, we assume that data packets are sent from terminal A to terminal B via the access node ANS, one or more ATM switches and the access node AND (forward direction) and the acknowledgments are returned from the terminal B to the terminal A via the access node AND, one or more ATM switches AN and ). As mentioned above, the access nodes can be divided into an interface card unit ICU and an ATM switch ASW. The interface card unit includes ATM adaptation layer 35 (AAL) functions for splitting and reconstructing IP data telegrams.

As in the example of Figure 8a, the acknowledgment delay is performed on the interface 104602 card unit. In this case, however, congestion is not monitored at the ATM switch portion of the access node, but at an ATM switch farther away in the ATM network. The ATM switch mentioned in Figure 9, which instructs the access node to delay acknowledgments, is the Node N1.

The network of Figure 9 has ABR flow control between the transmitting end system (ANS) and the receiving end system (AND). With respect to the RM cell stream on this bidirectional connection, each endpoint is both the transmitting and receiving end system. As shown in Fig. 9 for the forward information stream from the access node ANS to the access node 10 AND, the monitoring loop consists of two RM cell streams, one forward and one reverse. The access node ANS generates forward RM cells, which are inverted by the access node AND and sent back to the access node ANS as return RM cells. These reverse RM cells carry the feedback information provided by the network nodes and / or the access node AND 15. A network node in an ATM network, such as Node N1, can:

- add feedback information directly to the RM cells as they pass through the node in the forward or reverse direction,

- inform the source indirectly about the congestion by setting the EFCI (Explicit Forward Congestion Indication) bit in the headers of the data cells (user cells) traveling in the forward direction. In this case, the access node AND updates the reverse RM cells according to this congestion information,

- generate reverse RM cells.

Of scanning being of at least three different ways to control access node 25 feet FOR A delaying of acknowledgments from the network.

In RM cells, congestion information can be added, for example, to a 45-octet field “Function Specific Fields” or to a subsequent Reserved part, which is 6 bits long. The traffic parameters transmitted to the ABR-capable user in RM cells are described in ITU-T specification 1.371, clause 30 sa 5.5.6.3, and the RM cell structure in clause 7.1 of the same specification, from which the interested reader can find a more detailed description of RM cells.

The EFCI bit, in turn, is the middle bit in the 3-bit PTI (Payload Type Indicator) field of the ATM cell header.

According to this preferred embodiment of the invention, the corresponding associated node receives reverse RM cells containing congestion information when an overload or congestion is detected at a node in the ATM network. Based on this information, the ATM switch portion of the access node adjusts its transmission rate toward the ATM network, and the flow control mechanism delays acknowledgments on the reverse channel toward the traffic source. In this way, the TCP source automatically starts to reduce its transmission rate, or at least it does not increase its transmission rate as fast as it would otherwise. As mentioned earlier, this is because the delay reduces the rate at which the source increases the size of its congestion window.

As described above, end-to-end ABR flow control can be performed without changing the interoperable TCP protocol. In other words, ATM and TCP flow control loops can be implemented in an economically advantageous manner.

Figures 10 and 11 are timelines illustrating the exchange of segments between a TCP source and a TCP destination. The source is shown on the left and the destination on the right. Transmission and reception events are marked with 15 numbers starting with three.

Figure 10 is an example of how a source and a destination behave in a conventional network, i.e. a network which does not use the method according to the invention in the connection return route. Initially, the source is in the slow start phase. Suppose that the network load gradually increases, as a result of which the packet P10 sent at number 21 is eventually lost at the network congested point. After this, the source still sends packets because the acknowledgments it receives are in order. At number 37, the source finally notices that the received acknowledgment number was not in the correct order, in which case it stops transmitting.

At number 41, the timer trips and the source retransmits the packet P10. At the same time, the source enters the congestion prevention phase.

Figure 11 shows an example of data exchange when a network uses the present invention. In this case, an overload is detected after the target has sent the seventh acknowledgment (ACK7). As a result, this acknowledgment and subsequent acknowledgments (ACK8 ... ACK11) are delayed in the network.

As can be seen from the figure, the source starts to reduce its transmission rate already at number 24, continuing in the slow start phase. As shown in the figures, the traditional network behaves more unevenly; first, the 35 source sends a lot of packets and when congestion is detected, no packets are sent at all. The network using the invention, on the other hand, behaves much more stably because delaying the acknowledgments prevents the source from growing its congestion window as fast as in the known network. This makes it possible to reduce the buffering capacity of the access network.

Although the invention has been described above with reference to the examples according to the accompanying figures, it is clear that the invention is not limited thereto, but can be modified in many ways within the scope of the appended claims. The following is a brief description of some variations.

As stated above, the condition to be imposed on the user's terminal is that it acknowledges correctly received (error-free) data units. For this reason, the idea 10 can in principle be used in connection with any other protocol that sends acknowledgments and reduces its transmission rate if the acknowledgments are delayed. The formula used to calculate the absolute value of the delay can also vary in many ways. The measuring unit can inform about the load level in many ways; More than one bit can be used as ON / OFF type information or to indicate the value of the measured load. The signal (CS) informing about the load level may also contain information about the connections affected by the acknowledgment delay. User terminals may also have a wireless connection to the network.