EP0997020A2 - Gestion de flux dans un reseau de telecommunications - Google Patents

Gestion de flux dans un reseau de telecommunications

Info

Publication number
EP0997020A2
EP0997020A2 EP98935050A EP98935050A EP0997020A2 EP 0997020 A2 EP0997020 A2 EP 0997020A2 EP 98935050 A EP98935050 A EP 98935050A EP 98935050 A EP98935050 A EP 98935050A EP 0997020 A2 EP0997020 A2 EP 0997020A2
Authority
EP
European Patent Office
Prior art keywords
network
acknowledgments
load level
traffic
packet
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.)
Withdrawn
Application number
EP98935050A
Other languages
German (de)
English (en)
Inventor
Jian Ma
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Networks Oy
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FI972981A external-priority patent/FI972981A/fi
Priority claimed from FI973746A external-priority patent/FI104602B/fi
Priority claimed from FI980825A external-priority patent/FI980825A/fi
Application filed by Nokia Networks Oy, Nokia Oyj filed Critical Nokia Networks Oy
Publication of EP0997020A2 publication Critical patent/EP0997020A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L12/5602Bandwidth control in ATM Networks, e.g. leaky bucket
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/16Flow control; Congestion control in connection oriented networks, e.g. frame relay
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H04L47/323Discarding or blocking control packets, e.g. ACK packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/37Slow start
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q11/00Selecting arrangements for multiplex systems
    • H04Q11/04Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478Provisions for broadband connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5614User Network Interface
    • H04L2012/5615Network termination, e.g. NT1, NT2, PBX
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5629Admission control
    • H04L2012/5631Resource management and allocation
    • H04L2012/5632Bandwidth allocation
    • H04L2012/5635Backpressure, e.g. for ABR
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems
    • H04L12/5601Transfer mode dependent, e.g. ATM
    • H04L2012/5638Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665Interaction of ATM with other protocols
    • H04L2012/5667IP over ATM

Definitions

  • This invention relates generally to flow control in a telecommunica- tions network. More particularly, the invention relates to congestion control in a packet switched telecommunications network, especially in a network where Transmission Control Protocol (TCP) is used as a transport layer protocol.
  • TCP Transmission Control Protocol
  • TCP is the most popular transport layer protocol for data transfer. It provides a connection-oriented reliable transfer of data between two communicating hosts. (Host refers to a network-connected computer, or to any system that 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.
  • ATM Asynchronous Transfer Mode
  • ITU-T the international telecommuni- cation standardization organization
  • B-ISDN broadband integrated services digital network
  • the problems of conventional packet networks have been eliminated in the ATM 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 Internet).
  • 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). Con-source usually results in overload conditions. As a result, the buffers 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 users.
  • congestion 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.
  • the present invention relates to congestion control in packet switched networks. For the above-mentioned reasons, most of such networks are, and will in the foreseeable future be, TCP networks or TCP over ATM networks (i.e. networks in which TCP provides the end-to-end transport functions and the ATM network provides the underlying "bit pipes"). In the follow- ing, the congestion control mechanisms of these networks are described briefly.
  • ATM Forum has specified five different service categories which relate traffic characteristics and the quality of service (QoS) requirements to network behavior.
  • service classes are: constant bit rate (CBR), real-time variable bit rate (rt-VBR), non-real time variable bit rate (nrt-VBR), available bit rate (ABR), and unspecified bit rate (UBR).
  • CBR constant bit rate
  • rt-VBR real-time variable bit rate
  • nrt-VBR non-real time variable bit rate
  • ABR available bit rate
  • UBR unspecified bit rate
  • ABR Automatic Bit Rate flow control.
  • the basic idea behind the ABR flow control is to use special cells, so-called RM (Resource Management) cells, to adjust source rates.
  • RM Resource Management
  • ABR sources periodically probe the network state (factors such as bandwidth availability, the state of congestion and impending congestion) by sending RM cells intermixed with data cells.
  • the RM cells are turned around at the destination and sent back to the source.
  • ATM switches can write congestion information on these RM cells.
  • the source Upon receiving returned RM cells, the source can then increase, decrease or maintain its rate according to the information carried by the cells.
  • FIG. 1 illustrates a connection between a TCP source A and a TCP destination B in a network, where the connection path goes through an ATM network using ABR flow control.
  • ABR rate control becomes effective and forces the edge router R1 to reduce its transmission rate to the ATM network.
  • the purpose of the ABR control loop is to command the ATM sources of the network to reduce their transmission rate. If congestion persists, the buffer in the router will reach its maximum capacity. As a consequence, the router starts to discard packets, resulting in the reduction of the TCP congestion window (the congestion window concept will be explained in more detail later).
  • the network of Figure 1 comprises two independent control loops: an ABR control loop and a TCP control loop.
  • this kind of congestion control which relies on dual congestion control schemes on different protocol layers, may have an unex- pected and undesirable influence on the performance of the network.
  • the inner control loop ABR loop
  • TCP loop outer control loop
  • FIG. 2 illustrates this kind of network, i.e. a TCP over UBR network.
  • the nodes of this kind of network comprise packet discard mechanisms which discard packets or cells when congestion occurs. When a packet is discarded somewhere in the network, the corresponding TCP source does not receive an acknowledgment. As a result, the TCP source reduces its transmission rate.
  • the UBR service employs no flow control and provides no numerical guarantees on the quality of service; it is therefore also the least expensive service to provide.
  • plain UBR without adequate buffer sizes gives poor performance in a congested network.
  • more sophisticated congestion control mechanisms have been proposed.
  • One is the so-called early packet discard (EPD) scheme.
  • EPD early packet discard
  • an ATM switch drops entire packets prior to buffer overflow. In this way the throughput of TCP over ATM can be much improved, as the ATM switches need not transmit cells of a packet with corrupted cells, i.e. cells belonging to packets in which at least one cell is discarded (these packets would be discarded during the reassembly of packets in any case).
  • EPD scheme is that it is relatively inexpensive to implement in an ATM switch.
  • a detailed description of the EPD method can be found, for example, in an article by A. Romanow and S. Floyd, Dynamics of TCP Traffic over ATM Networks, Proc. ACM SIGCOMM '94, pp. 79-88, August 1994.
  • the EPD method still deals unfairly with the users. This is due to the fact that the EPD scheme discards complete packets from all connections, without taking into account their current rates or their relative shares in the buffer, i.e. without taking into account their relative contribution to an overload situation.
  • several variations for selective drop policies have been proposed. One of these is described in an article by Rohit Goyal, Performance of TCP/IP over UBR+, ATM_Forum/96-1269. This method uses a FIFO buffer at the switch, and performs some per-VC ac- counting to keep track of the buffer occupancy of each virtual circuit. In this way only cells from overloading connections can be dropped, whereas the underloading connections can increase their throughput.
  • the prior art congestion control methods still have the major drawback that there is no means of giving early warning to the traffic source when excessive load is detected in the network. In other words, the traffic source is not informed quickly of overload so that it could reduce its output rate.
  • the purpose of the invention is to eliminate the above-mentioned drawback and to create a method by means of which it is possible, using a simple implementation, to inform the traffic source at a very early stage that the network is becoming overloaded or congested and to ask the source to slow down its transmission rate.
  • the purpose is also that the method allows the co-operation of TCP and ATM flow control mechanisms in an efficient way. This goal can be attained by using the solution defined in the independent patent claims.
  • the basic idea of the invention is to delay the acknowledgments being transferred from the destination towards the sender. This can be done at the same network point where congestion has been detected, or, alternatively, a network point detecting overload or congestion can direct another network point to delay the acknowledgments.
  • congestion control is performed on the return path of the connection, whereas prior art systems control traffic on the forward path.
  • the network according to the present invention delays acknowledgments on the return path and thus causes the TCP source to reduce its output rate.
  • the invention offers an inexpensive solution for giving the TCP source an early warning of impending overload or congestion in the network. It is also important to note that the transport protocol TCP itself does not have to be amended in any way. To put the invention into use, a congestion control algorithm must be introduced into the network, but for this purpose many existing control algorithms in the TCP over UBR can be utilized with only slight modifications. Moreover, by means of the present invention the variations in the output rate of the TCP source can be smoothed, which in turn results in better bandwidth utilization. Further, because the amount of variation is lessened, the buffer capacity requirements are also reduced.
  • load level information from an ATM network point is transported in RM cells to a node providing access to the ATM network, and the acknowledgments are delayed in said access node on the basis of the information contained in the RM cells.
  • the TCP and the ATM flow control mechanisms can be made dependent on each other so that they function efficiently together.
  • Figure 1 illustrates a TCP connection path through an ABR-based ATM subnetwork
  • Figure 2 illustrates a TCP connection path through a UBR-based ATM subnetwork
  • Figure 3 illustrates the flow control loop according to the present invention in a TCP over ATM network
  • Figure 4a illustrates one possible implementation of the new method in an IP switch
  • Figure 4b is a time diagram showing the significant moments of the imple- mentation of Figure 4a
  • Figure 5 is a flow chart illustrating a method for determining delay values
  • Figure 6a illustrates another possible implementation of the delaying of acknowledgments in a switch
  • Figure 6b illustrates an alternative way of using acknowledgment buffers
  • Figure 7a illustrates one way of applying the method to an IP network
  • Figure 7b illustrates another way of applying the method to an IP network
  • Figure 8a illustrates one way of applying the method to an ATM network
  • Figure 8b illustrates another way of applying the method to an ATM network
  • Figure 9 illustrates the interworking of the TCP and ATM flow control loops according to a preferred embodiment of the invention
  • Figure 10 illustrates an example of packet transfer between the traffic source and the traffic destination in a known TCP network
  • Figure 11 illustrates an example of packet transfer between the traffic source and the traffic destination in a TCP network utilizing the method ac- cording to the invention
  • Figure 12 is a flow diagram illustrating a further embodiment of the method.
  • Figure 13 illustrates one possible implementation of the method according to Figure 12 in an IP switch.
  • Figure 3 illustrates the basic principle of the invention by showing a connection between two user terminals (A and B) in a TCP over ATM network, i.e. the user terminals using TCP as a transport layer protocol.
  • a connection between two user terminals (A and B) in a TCP over ATM network i.e. the user terminals using TCP as a transport layer protocol.
  • the access nodes (AN1 and AN2) of the user terminals only one intermediate node (N1) and the transmission lines (TL1 , TL2) connecting the nodes are shown.
  • the TCP connection between the hosts A and B starts out, the same as any other TCP connection, with a negotiation between the hosts to open the connection.
  • This initial negotiation is called a three-way handshake, as three opening segments are transmitted during this handshake phase.
  • 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 which is the information unit used by IP.
  • the hosts inform each other for example of the maximum segment size they will accept. This is done to avoid fragmentation of the TCP segments, as fragmentation would slow down the performance of the TCP connection considerably.
  • the hosts After the initial handshake has been completed, the hosts begin to send data by means of the TCP segments. Each uncorrupted TCP segment, including the handshaking segments, is acknowledged.
  • host A sends one TCP segment to host B.
  • host A adds an IP header to this TCP segment to form an IP datagram.
  • This datagram is converted into standard ATM cells in an 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 host B.
  • This access node reconstructs the original IP datagram from the arriving cells and sends the IP datagram to host B.
  • Host B removes the IP header to reveal the TCP segment. If the segment is received correctly, host B sends an acknowledging TCP segment ACK1 back to host A. Up till now the network has operated in a known manner.
  • the load of the network is monitored in the access node AN1 , for example, by monitoring the occupancy of one or more of the buffers buffering the traffic to the ATM network. If overload is detected, i.e. if buffer occupancy exceeds a predefined level, a congestion notification CM is sent inside the node to delay the acknowledgments traveling at that moment through the switch towards the traffic sources. Thus, also our exemplary acknowledgment (ACK1) is delayed when passing through access node AN1, provided that node AN1 experiences overload during that particular time period.
  • TCP is one of the few transport protocols that natively has a congestion control mechanism. The solution of the invention relies on this known TCP control mechanism, i.e. no other control mechanisms are needed in the source or in the destination. 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 sender as a measure of the capacity of the network.
  • the TCP source can never send 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
  • 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 in the beginning.
  • the source receives an acknowledgment, it increments CWND by one, and, as a consequence, sends two 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.
  • the source does not receive acknowledgment and times out.
  • the source sets SSTHRES to half the CWND value when the packet was lost. More precisely, SSTHRES is set to max ⁇ 2, min ⁇ CWND/2, Wrcvr ⁇ , and CWND is set to one.
  • the source enters the congestion avoidance phase. During the congestion avoidance phase, the source increments its CWND by 1/CWND every time a segment is acknowl- edged.
  • TCP congestion control mechanism does not in any way change the above-described known TCP congestion control mechanism, the latter is not described in more detail here.
  • anyone interested in the matter can find more detailed information from several books describing the field. (For example, see W. Richard Stevens, TCP/IP Illustrated Volume 1 , The protocols, Addison- Wesley, 1994, ISBN 0-201-63346-9)
  • the TCP source which operates in the manner described above, automatically starts to slow down its transmission rate, or at least it does not increase its transmission rate as quickly as it otherwise would. This is because the delay slows down the rate at which the source increases the size of its congestion window.
  • FIG. 4a illustrates this principle by showing an example in which the acknowledgments are delayed at the output port OP of an IP switch.
  • a load measurement unit LMU measures the load level of the switch by measuring the fill rates (occupancies) of the buffers buffering the traffic passing through the switch in the forward direction. It is to be noted that the load level can be determined in any known manner.
  • IP datagrams passing through the switch in the backward di- rection are first routed to their correct output port. At this port the received datagrams are stored in a FIFO-type output buffer OB.
  • a traffic splitter TS reads the stored packets out from the output buffer, one packet at a time from the first memory location ML1 of the buffer.
  • the traffic splitter operates in the following ways. If the congestion signal CS from the load measurement unit indicates that the load of the switch is below a predefined level, the traffic splitter forwards all the datagrams (packets) directly to the outgoing link OL, irrespective of whether they include acknowledgments or not.
  • the traffic splitter starts to read the acknowledgment bit of each TCP header inside each IP datagram. If this bit is valid, i.e. if the datagram includes an acknowledgment, the traffic splitter forwards the packet to an acknowledgment buffer AB. If the bit is not valid, the traffic splitter forwards the packet directly to the outgoing link OL. Thus, only packets including an acknow'edgment are delayed.
  • each IP datagram is delayed for a certain period.
  • the length of the period is preferably directly proportional to the current load level measured by the unit LMU.
  • ACKTo denotes the moment in time when a packet is output from the acknowledgment buffer to the link
  • Figure 4b illustrates the moments when the packets leave the traffic splitter and the acknowledgment buffer, respectively. It is assumed that exces- sive load is detected after ACKTo(7) (until then the acknowledgments have not been delayed). If the congestion signal received by the delay control unit DCU indicates that the level of the load has exceeded a predefined value, the delay control unit executes an algorithm defining how long the next packet to be transferred to the link should be delayed. The calculated value may depend on one or more parameters, such as the current traffic rate, the current buffer occupancy, or the previous delay value (d ). As can be seen from Figure 4b, the value of the delay may vary from one packet to another.
  • Figure 5 is a flow chart illustrating an example of the algorithm which is executed by the delay control unit for each packet to be read out from the acknowledgment buffer AB.
  • the measured delay is the actual delay as measured between the moment when a packet is received by the acknowledgment buffer and the moment when that packet is read out from the acknowledgment buffer. This delay can be measured as a mean value over a certain period of time or over a certain number of packets.
  • the delay control unit can perform this measurement.
  • the delay control unit calculates the delay value d with the formula: d ⁇ ad ⁇ - d-aJd M (2).
  • the purpose of the second term in formula (1) is to smoothly in- crease the delay when congestion is detected, and in formula (2) to smoothly decrease the delay when the network is recovering from congestion.
  • Figure 6a shows the solution according to Figure 4a in a shared buffer switch architecture.
  • all the packets are buffered in a shared buffer SB prior to routing each packet to the correct out- put port OP, of the switch.
  • the embodiment of Figure 6a correspond to the embodiment shown in Figure 4a.
  • the delay control unit DCU (not shown in Figure 6a) can also be implemented as a common unit for all the output ports.
  • the acknowledgment buffer contains packets from several connections, and all the packets are delayed according to the same delay algorithm.
  • the packets may be stored on a per-connection basis at each output port, i.e. the data packets of each IP connection (or each TCP connection) can be stored in a separate buffer.
  • each buffer can be a FIFO-type buffer, as the packets of a single queue do not have to be re-sequenced even though different connections were delayed in different ways.
  • the relative share of each connection in the forward buffer can be determined through measurement of the load level, and the connections can be delayed on the basis of the measured values. In this way the acknowledgments of connections loading the network more heavily can be delayed longer.
  • Figure 6b illustrates this alternative embodiment in which the output port has a buffer unit BFU, including separate queues for at least some of the connections.
  • the buffers can, for example, be shift- register type memories, allowing the re-sequencing of packets so that packets of underloading connections can pass packets of overloading connections.
  • the congestion control method in accordance with the invention can be utilized in packet networks.
  • the network comprises user terminals, network access points providing access to the network, and switches.
  • the user terminals act as traffic sources and destinations, i.e. as points transmitting and receiving data.
  • the switches can be packet switches or ATM switches.
  • An access point can be, for example, a router, or an access point can carry out packet assembling/reassembling, routing or switching.
  • the delaying of acknowledging packets is preferably carried out at the access points, but it can also be carried out in the switches within the network, as described later.
  • Figures 7a and 7b show two different ways of implementing the invention in an IP network.
  • the congestion detection as well as the delaying of acknowledgments are carried out within the access switch IPS1 , which provides access to the IP network.
  • congestion detection is carried out in the access node, whereas the delaying of acknowledgments is carried out in the TCP/IP protocol stack of the user terminal UT.
  • Congestion notifications CS are transmitted to the user terminal, where the packets with acknowledgments are delayed in the above-described manner prior to their being sent to the TCP source.
  • FIGS 8a and 8b show two different ways of implementing the invention in association with an ATM network.
  • the congestion detection and the delaying of acknowledgments are carried out in 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 the ATM Adaptation Layer (AAL) functions for the segmentation and reassembly of the IP datagrams.
  • Congestion is monitored in the ATM switch part of the node by monitoring, for example, the fill rates (occupancies) of the buffers buffering the subscriber traffic towards the network. Congestion notifications are transferred to the interface card unit, where the reassembled IP packets are delayed in the above-described manner.
  • AAL ATM Adaptation Layer
  • FIG. 8b congestion is monitored in switch ASW, whereas the acknowledging packets are delayed in the TCP/IP protocol stack of the user terminal UT.
  • the embodiments of Figures 7a and 8a are the more advantageous ones because it is much more economical to implement the delaying of acknowledgments in a single access node than in several terminals located in user premises. Furthermore, it is naturally preferable that the user terminals need not be amended in any way to put the invention into use. As mentioned earlier, one network element in the connection path can command another network element of the same path to perform the de- laying.
  • Figure 9 illustrates this principle in a TCP over ATM network by showing a connection between two user terminals (A and B), using TCP as a transport layer protocol.
  • the access nodes In addition to the access nodes (ANS and AND) of the user terminals, only one intermediate ATM node (N1) and the transmission lines connecting the nodes are shown. It is assumed that the network nodes have channels in two directions; a forward channel and a backward channel.
  • the data packets are sent from terminal A to terminal B via access node ANS, one or more ATM switches, and access node AND (forward direction), while the acknowledg- ments are returned from terminal B to terminal A via access node AND, one or more ATM switches, and access node ANS (backward direction).
  • the access nodes can be divided into an interface card unit ICU and an ATM switch ASW.
  • the interface card unit includes the ATM Adaptation Layer (AAL) functions for the segmentation and reassembly of the IP datagrams.
  • AAL ATM Adaptation Layer
  • the delaying of acknowledgments is performed in the interface card unit.
  • congestion is not monitored in the ATM switch part of the access node, but in an ATM switch located further within the ATM network.
  • said ATM switch which commands the access node to delay the acknowledgments, is switch N1.
  • ABR flow control occurs between a sending end-system (ANS) and a receiving end-system (AND).
  • ANS sending end-system
  • AND receiving end-system
  • each termination point is both the sending and the receiving end-system.
  • a network node within the ATM network such as node N1 , can:
  • the access node AND updates the backward RM cells according to this congestion information, - generate backward RM cells.
  • the congestion information can be inserted, for exam- pie, in the 45 octet long "Function Specific Fields", or in the subsequent "Reserved" part having a length of 6 bits.
  • the traffic parameters forwarded to the user of ABR capability via RM cells are described in item 5.5.6.3 of the ITU-T specification 1.371 , and the structure of an RM cell in item 7.1 of said specification, where an interested reader can find a more detailed description of RM cells.
  • the EFCI bit is the middlemost bit in the 3 bit wide PTI (Payload Type Indicator) field in the ATM cell header.
  • the correspond- ing access node when overload or congestion is detected at an ATM network node, receives backward RM cells containing the congestion information.
  • the ATM switch part of the access node adjusts its output rate towards the ATM network, and the flow control mechanism delays the acknowledgments traveling towards the traffic source on the backward channel.
  • the TCP source automatically starts to slow down its transmission rate, or at least it does not increase its transmission rate as quickly as it otherwise would. As mentioned earlier, this is because the delay slows down the rate at which the source increases the size of its congestion window.
  • the end-to-end ABR flow control can be performed without changing the interworking TCP protocol.
  • the interworking of the ATM and TCP flow control loops can be implemented in an inexpensive way.
  • Figures 10 and 11 are time lines illustrating the exchange of segments between a TCP source and a TCP destination.
  • the source is shown on the left side and the destination on the right side.
  • the transmission and reception events have been marked with numbers starting from 3.
  • Figure 10 gives an example of how the source and the destination behave in a conventional network, i.e. in a network without the implementation of the inventive method on the return path of the connection.
  • the source is in the slow start phase. Let us assume that the load of the network increases gradually, and, as a result, packet P10 transmitted at number 21 is lost in the overloaded network point. After this, the source still sends packets, as the acknowledgments it receives are in sequence. At number 37 the source finally notices that the acknowledgment number received was out of sequence and stops transmitting. At 41 the timer of the source goes off and the source retransmits packet P10. Simultaneously the source moves over to the congestion avoidance phase.
  • FIG 11 gives an example of the data exchange when the network utilizes the present invention.
  • overload is detected after the destination has transmitted the seventh acknowledgment (ACK7).
  • ACK7 acknowledgment
  • ACK8...ACK11 acknowledgments
  • the source begins to slow down its output rate, continuing in the slow start phase.
  • the conventional network behaves in a more uneven way, i.e. first the source sends a lot of packets, and when congestion is detected, no packets are sent.
  • a network implementing the present invention behaves in a much smoother way. This is because delaying the acknowledgments prevents the source from incrementing its congestion window as quickly as in the known network. Because of this, the buffering capacity of the access network can be diminished.
  • the above-described method can also be used together with other flow control mechanisms. As the above-described method needs a long acknowledgment buffer, if the congestion situation lasts for a long time, it may in some applications be advantageous to combine it with another mechanism which takes care of the more severe congestion situations.
  • the delaying of acknowledgments is used together with a method which is otherwise similar to the above method but which generates duplicate acknowledgments, instead of delaying acknowledgments. By duplicating the acknowledgments the TCP source can be made to slow down its output rate, i.e. duplication has a same kind of effect on the TCP source as delaying.
  • FIG. 12 is a flow chart illustrating the combinatory method. If congestion is not detected on the forward path, the acknowledgments are forwarded without delay and with the incoming acknowledgment number.
  • phase 112 If the load measurement detects that the load level on the forward path exceeds a predetermined value (phase 111), it is tested (phase 112) whether the fill rate of the acknowledgment buffer has exceeded a predetermined value. If this is the case, duplicate acknowledgments are generated. Otherwise acknowledgments are only delayed. Thus, if congestion occurs only slightly and for a short period, delaying of acknowledgments is performed. However, should there be a more severe congestion situation, the system always moves over to gener- ate duplicate acknowledgments. This means that a network node sends towards the source M successive acknowledgments in which the acknowledgment number, which indicates the next sequence number that the destination expects to receive, are equal to each other.
  • FIG 13 illustrates how this preferred embodiment is implemented in the node of Figure 4a.
  • the IP datagrams passing through the switch in the backward direction are first routed to their correct output port.
  • the received datagrams are stored in a FIFO- type output buffer OB.
  • the traffic splitter reads the stored packets out from the output buffer, one packet at a time from the first memory location ML1 of the buffer.
  • the traffic splitter forwards all the datagrams (packets) directly to the outgoing link OL, irrespective of whether they include acknowledgments or not.
  • the traffic splitter starts to read the acknowledgment bit of each TCP header inside each IP datagram. If this bit is valid, i.e. if the datagram includes an acknowledgment, the traffic splitter for- wards the packet to an acknowledgment buffer AB. If the bit is not valid, the traffic splitter forwards the packet directly to the outgoing link OL. Thus, only packets including an acknowledgment are delayed.
  • each IP datagram is delayed for a certain period.
  • the length of the period is preferably directly proportional to the current load level measured by the unit LMU. After the delay period for each outgoing acknowledgment packet has elapsed, the packet is sent to the outgoing link.
  • the load measurement unit LMU also measures the fill rate of the acknowledgment buffer AB. If this fill rate exceeds a predetermined value, the load measurement unit sends the control unit CU a second congestion signal CS2 indicating that the control unit should now begin to produce duplicate acknowledgments.
  • the duplication can be done for example by modifying the acknowledgment number of the acknowledgments in the packet buffer OB.
  • the traffic splitter is also informed to direct all the traffic directly to the output link. The command can be given either by the load measurement unit or by the control unit.
  • a prerequisite for a user terminal is that it acknowledges correctly received (i.e. uncorrupted) data units. Therefore, the idea can in principle be applied to any other protocol which sends acknowledgments and slows down its output rate if the acknowledgments are delayed.
  • the formula used for calculating the absolute delay value can also vary in many ways.
  • the measurement unit can inform about the load level in many ways; as an ON/OFF type information, or more than one bit can be used to indicate the value of the measured load.
  • the signal (CS) informing about the load level can also include information on the particular connections that should be subject to delaying of acknowledgments.
  • User terminals can also have wireless access to the network.

Landscapes

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

Abstract

L'invention concerne un procédé de gestion de surcharge dans un réseau de commutation par paquets, en particulier dans un réseau où le protocole de contrôle de transmission (TCP) est utilisé en tant que protocole de couche transport. Afin d'informer la source de trafic, dès le début, que le réseau est sur le point d'être surchargé ou encombré, les accusés de réception se dirigeant vers la source sont retardés lorsque le niveau de charge du réseau dépasse une valeur prédéterminée.
EP98935050A 1997-07-14 1998-07-14 Gestion de flux dans un reseau de telecommunications Withdrawn EP0997020A2 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
FI972981A FI972981A (fi) 1997-07-14 1997-07-14 Vuonohjaus tietoliikenneverkossa
FI972981 1997-07-14
FI973746A FI104602B (fi) 1997-07-14 1997-09-22 Vuonohjaus tietoliikenneverkossa
FI973746 1997-09-22
FI980825A FI980825A (fi) 1998-04-09 1998-04-09 Ylikuormituksen hallinta tietoliikenneverkossa
FI980825 1998-04-09
PCT/FI1998/000591 WO1999004536A2 (fr) 1997-07-14 1998-07-14 Gestion de flux dans un reseau de telecommunications

Publications (1)

Publication Number Publication Date
EP0997020A2 true EP0997020A2 (fr) 2000-05-03

Family

ID=27241713

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98935050A Withdrawn EP0997020A2 (fr) 1997-07-14 1998-07-14 Gestion de flux dans un reseau de telecommunications

Country Status (6)

Country Link
EP (1) EP0997020A2 (fr)
JP (1) JP2001510957A (fr)
CN (1) CN1267419A (fr)
AU (1) AU745204B2 (fr)
NO (1) NO20000171L (fr)
WO (1) WO1999004536A2 (fr)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1240753A1 (fr) 1999-12-13 2002-09-18 Nokia Corporation Procede de regulation de congestion dans un reseau commute par paquets
US7126916B1 (en) * 2000-08-24 2006-10-24 Efficient Networks, Inc. System and method for packet bypass in a communication system
FI20002320A (fi) * 2000-10-20 2002-04-21 Nokia Corp Eston hallinta langattomissa tietoliikenneverkoissa
FI20002848A (fi) * 2000-12-22 2002-06-23 Nokia Corp Vuon valvonta tietoliikenneverkossa
US20040090936A1 (en) * 2001-03-16 2004-05-13 Renaud Cuny Method and system for reducting traffic flow to a mobile node during handoff situations
US7143131B1 (en) 2001-05-04 2006-11-28 Microsoft Corporation Transmission control protocol
DE10147771C2 (de) * 2001-09-27 2003-07-31 Siemens Ag Verfahren zur Desensibilisierung des paketbasierten Anschlusses von Teilnehmern an ein Vermittlungssystem
JP3639556B2 (ja) 2001-12-12 2005-04-20 富士通株式会社 VoIPネットワークの輻輳制御システム
US6920504B2 (en) * 2002-05-13 2005-07-19 Qualcomm, Incorporated Method and apparatus for controlling flow of data in a communication system
EP1376944B1 (fr) * 2002-06-18 2006-05-10 Matsushita Electric Industrial Co., Ltd. Augmentation du débit de transmission à l'initiative du récepteur
US20060165029A1 (en) * 2002-12-19 2006-07-27 Koninklijke Philips Electronics N.V. Protecting real-time data in wireless networks
US7225266B2 (en) * 2002-12-20 2007-05-29 Nokia Corporation Adaptive delayed ACK switching for TCP applications
JP3712399B2 (ja) * 2003-03-17 2005-11-02 ボーダフォン株式会社 局装置
US8004981B2 (en) * 2003-06-17 2011-08-23 Cisco Technology, Inc. Methods and devices for the coordination of flow control between a TCP/IP network and other networks
WO2005039117A1 (fr) 2003-10-10 2005-04-28 Thomson Licensing Priorite au protocole de datagramme d'utilisateur par rapport au trafic de protocole de controle de transmission par ralentissement du debit de transmission du protocole de controle de transmission
US7440399B2 (en) * 2004-12-22 2008-10-21 Qualcomm Incorporated Apparatus and method for efficient transmission of acknowledgments
JP4891392B2 (ja) 2006-04-13 2012-03-07 ドルビー ラボラトリーズ ライセンシング コーポレイション 無線処理システム装置のキュー長の推定および無線ネットワークにおける信号受信品質の推定
JP4664243B2 (ja) * 2006-06-29 2011-04-06 富士通株式会社 通信装置
US8477608B2 (en) 2006-10-26 2013-07-02 Unwired Planet, Llc Method and receiver for controlling the conformance of a data flow in a communication system to a traffic definition
CN101114999B (zh) * 2007-08-26 2010-08-04 上海华为技术有限公司 数据发送控制方法及数据传输设备
CN101369877B (zh) * 2007-12-27 2012-08-22 华为技术有限公司 无线传输控制协议处理方法和设备
CN103299675B (zh) * 2011-01-12 2019-03-01 瑞典爱立信有限公司 用于tcp依赖的流控制的自适应相对比特率管理器
US9148386B2 (en) * 2013-04-30 2015-09-29 Cisco Technology, Inc. Managing bandwidth allocation among flows through assignment of drop priority
JP6303452B2 (ja) 2013-12-02 2018-04-04 富士通株式会社 通信ノード

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2540930B2 (ja) * 1988-02-19 1996-10-09 日本電気株式会社 輻輳制御装置
FR2655223B1 (fr) * 1989-11-27 1992-02-07 Cit Alcatel Procede de gestion des flux dans un reseau numerique de telecommunication a integration de services, a large bande, et reseau pour le mise en óoeuvre de ce procede.
US5815667A (en) * 1995-11-28 1998-09-29 Ncr Corporation Circuits and methods for intelligent acknowledgement based flow control in a processing system network
JPH09270823A (ja) * 1996-03-29 1997-10-14 Fujitsu Ltd Atmルータ
US6038216A (en) * 1996-11-01 2000-03-14 Packeteer, Inc. Method for explicit data rate control in a packet communication environment without data rate supervision

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9904536A2 *

Also Published As

Publication number Publication date
AU8443498A (en) 1999-02-10
WO1999004536A2 (fr) 1999-01-28
JP2001510957A (ja) 2001-08-07
CN1267419A (zh) 2000-09-20
AU745204B2 (en) 2002-03-14
NO20000171L (no) 2000-03-13
NO20000171D0 (no) 2000-01-13
WO1999004536A3 (fr) 1999-04-08

Similar Documents

Publication Publication Date Title
US6882624B1 (en) Congestion and overload control in a packet switched network
AU745204B2 (en) Flow control in a telecommunications network
JP4436981B2 (ja) ハイブリッドip−atmネットワーク内で混雑状態を管理するためのecnベースの方法
US6490251B2 (en) Method and apparatus for communicating congestion information among different protocol layers between networks
US7046631B1 (en) Method and apparatus for provisioning traffic dedicated cores in a connection oriented network
US7046630B2 (en) Packet switching network, packet switching equipment and network management equipment
KR100298357B1 (ko) 프레임릴레이-에이티엠간인터페이스회로및그작동방법
US6587436B1 (en) Method and apparatus for allocation of available bandwidth
KR100411447B1 (ko) 티씨피 혼잡 제어 방법
US7068606B1 (en) Overload control method for a packet-switched network
EP1068766B1 (fr) Controle de la saturation dans un reseau de telecommunication
EP1066703A2 (fr) Controle de la saturation dans un reseau de telecommunication
Goyal Traffic management for TCP/IP over Asynchronous Transfer Mode (ATM) networks
Bonaventure et al. Is VBR a solution for an ATM LAN?
FI104602B (fi) Vuonohjaus tietoliikenneverkossa
JP2000253018A (ja) Atm優先制御ipゲートウェイ装置およびatm優先制御ipルーティング装置ならびにそれらの処理方法
Iliadis Performance of TCP traffic and ATM feedback congestion control mechanisms
Karabek A native ATM protocol architecture design and performance evaluation
Boyer et al. Accelerated Signalling for the Internet over ATM (ASIA)
Hasegawa et al. Protocol architecture of high speed TCP/IP service over international ATM network
Ren et al. Performance of TCP in IP/ATM internetworks
Pippas et al. On the extension of ABR flow control to legacy LANs
Ano et al. Experimental TCP performance evaluation on diffserv AF PHBs over ATM SBR service
Birdi A study of TCP behavior over UBR and ABR
Iliadis et al. Performance of TCP traffic and ABR congestion control mechanisms

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000125

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL PAYMENT 20000103;LT PAYMENT 20000103;LV PAYMENT 20000103;MK PAYMENT 20000103;RO PAYMENT 20000103;SI PAYMENT 20000103

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA CORPORATION

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20030520