JP2006005775A - Deterioration cause determination method of network performance, and congestion control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to take an appropriate action according to each cause by simply determining that a cause of increase such as a packet loss ratio during streaming, is not packet rejection by network congestion, but a link/node failure. <P>SOLUTION: If packet loss occurs on a burst, it is determined that the cause is the link/node failure. In this case, the action is different from the case that the cause is network congestion, it is prevented that received stream quality deteriorates further by not reducing the stream transmission rate. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to streaming, and more particularly to determination of the cause of network performance degradation and congestion control based on the determined cause.

  It is well known to send data that continues in the time axis direction such as so-called multimedia including voice and video via an IP network in a streaming system, and many such services are already provided on the Internet. .

  In performing streaming, the transport protocol of the IP network must regulate the transmission rate of the corresponding packet stream in accordance with the traffic encountered until the packet stream reaches the destination via the network. As this traffic increases, the transport protocol must lower the packet stream transmission rate. This maintains a degree of fairness among competing users trying to simultaneously use limited network resources in the packet stream transfer path. Such a rate reduction procedure is generally called congestion control.

  In TCP, a widely used data transport protocol, congestion control is based on end-to-end statistics such as packet loss rate and round trip time (RTT). Packets are always retransmitted to ensure that they arrive in the exact correct order.

  In media streaming, TCP is not suitable as a transport protocol. This is because the packet retransmission always means that packet retention may occur, and as a result, the packet may not reach the client within the time required for continuous playback. is there.

  However, no matter what transport protocol the media streaming server employs, such transport protocol needs to be fair to a large amount of TCP traffic. That is, such a transport protocol must be TCP compatible in the sense that it does not occupy a wider bandwidth than a TCP connection under the same network conditions. As an example of a transport protocol having TCP affinity, there is a method in which an interval T is opened between packets to be transmitted according to a well-known TCP affinity congestion control equation (1).

In the above equation, ε _R , μ _R , and σ _R ² represent the packet loss rate from the server to the client, the average of the round trip time between the server and the client, and the estimated value of dispersion, respectively. The details of Equation (1) are described in Non-Patent Document 1 below.
S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-based congestion control for unicast applications" ACM SIGCOMM, 2000

However, as shown in Non-Patent Document 2 below, it has been found that the performance degradation of the Internet can be caused by a link / node failure rather than network congestion. In the case of a link / node failure, there are no users competing for the limited network resources, so the streaming server instead of reducing the transmission rate for fairness among competing users, There is a need to focus on improving tolerance to media stream errors in order to deal with increased bucket losses and delays due to node failures.
G. Iannaccone, C.-N. Chuah, R. Mortier, S. Bhattacharyya, and C. Diot, "Analysis of Link Failures in an IP Backbone," ACM SIGCOMM Internet Measurement Workshop, November, 2002

  The two factors of the above-mentioned Internet performance degradation and the solutions in the related art will be further described below.

  Two main factors of performance degradation of streaming such as video on the Internet are the above-mentioned network congestion and routing instability due to link / node failure. In conventional streaming on the Internet, if packet loss or delay is observed, it is assumed that it is due to network congestion only, and congestion control is performed to reduce the packet transmission rate accordingly.

  However, according to recent research, the degree of congestion within the core IP backbone in the network is usually negligible, so the impact of this congestion is rather rather for applications where delays such as streaming are problematic. It was found that there were few.

  On the other hand, a link / node failure, that is, a link failure such as a disconnection of a communication link due to an optical fiber disconnection, or a node failure due to a failure of a device such as a router or an abnormality of a router configuration is very common in daily operation of a network. It turns out that this is a normal occurrence. Rerouting after a link / node failure may take tens of seconds even within a single domain, and interdomain route changes made using BGP (Border Gateway Protocol) may not converge until a few minutes. is there. In the transient state period until the route converges, the packet may be lost by entering the wrong path, or the delay time may be increased by entering the routing loop.

  In the currently proposed rate-adaptive media streaming method, which is “not aware” that the degradation in network performance is due to link / node failure, when packet loss or delay is observed on the network, Interpretation is due to congestion, and congestion control is performed to reduce the packet transmission rate using a known congestion control algorithm. Such congestion control by misinterpreting observed network behavior statistics unnecessarily reduces streaming data transmission rates such as real-time video streaming, resulting in playback The quality is further deteriorated compared to the case where no measures are taken.

  If packet loss is observed on the network, if it is due to link / node failure rather than network congestion, a better response to such packet loss is to maintain packet transmission rate and automatic retransmission Enhancing packet protection using automatic retransmission request (ARQ) and / or forward error protection (FEC). In other words, it is important to identify which of the above-mentioned two causes of packet loss and take appropriate measures in order to maintain the quality of the playback result of streaming data.

  In order to perform this identification, for example, a network proxy or a router that detects congestion is arranged on the network so that a link / node failure may be notified to the streaming server or client. Can be considered. However, such a network configuration is costly to implement, and is not scalable, and needs to be deployed all over the network at once. Therefore, there is a big problem in adopting it in an existing network or a large-scale network.

  It is an object of the present invention to solve the above-mentioned problems of the prior art, easily identify which of the above-mentioned two factors is causing degradation of network performance, and take appropriate measures.

  In order to achieve the above-described problem, in the present invention, a burst state is generated in a stream sent from a streaming server to a client via a network until reaching the client or a predetermined node on the network. A network performance degradation cause determination method for determining that a link / node failure has occurred when a packet loss occurs is provided.

In this determination method, when a predetermined number of consecutive packets in the stream are lost, it can be determined that a burst-like packet loss has occurred.
In this method, the determination of the link / node failure can be prioritized over the determination of the network congestion.

  In this determination method, it can be further determined that network congestion has occurred when the packet loss rate and / or the land trip time has increased.

  Further, in this determination method, when it is determined that a link / node failure has occurred, and it is determined that statistical information regarding network performance has stabilized, it is determined that the link / node failure has been recovered. it can.

  In this determination method, the statistical information regarding the performance of the network may further include a packet loss rate or a round trip time.

  In this determination method, the network may be an IP network.

  In addition, in order to achieve the above-mentioned problem, bursty packet loss occurs until the client or a predetermined node on the network is reached in the stream sent by streaming from the streaming server to the client via the network. If it is determined that a link / node failure has occurred and network congestion has occurred while no link / node failure has occurred, the stream transmission rate from the streaming server is reduced. It is possible to provide a congestion control method that executes processing, and when it is determined that a link / node failure has occurred, does not execute processing for reducing the stream transmission rate.

  9. The congestion control method according to claim 8, wherein in the congestion control method, when it is determined that the link / node failure has occurred, a process for increasing an error recovery capability of the stream is performed.

  In this congestion control method, the process for increasing the error recovery capability can be any one of the use of an error correction code, the use of an error correction code having a higher error correction capability than the normal use, and retransmission of a lost packet. .

  In this congestion control method, it is further possible to determine that a burst-like packet loss has occurred when a predetermined number of consecutive packets in the stream are lost.

  In this congestion control method, it can be further determined that network congestion has occurred when the packet loss rate and / or the land trip time has increased.

  Furthermore, in this congestion control method, when it is determined that a link / node failure has occurred, and it is determined that statistical information regarding network performance has stabilized, it is determined that the link / node has recovered from the failure. Can do.

  In this congestion control method, the statistical information regarding the performance of the network may further include a packet loss rate or a round trip time.

  By using the present invention, it is possible to reliably identify each increase in packet loss due to either network congestion or link / node failure. Further, by taking measures suitable for the identified cause, it is possible to minimize the deterioration of the quality of the streaming data. In addition, the present invention can be realized at low cost and can be applied over a wide range from a small-scale network to a large-scale network. Furthermore, the present invention does not need to be applied to the entire network all at once, and can be applied sequentially from a necessary or possible streaming server, so that the present invention can be easily applied to an existing network. Therefore, it is advantageous for practical use.

  An embodiment of the present invention will be described by taking streaming on the network 100 as shown in FIG. 1 as an example. In FIG. 1, it is assumed that video data and the like are sent from the streaming server 101 to the client 111 by streaming. Packets sent from the server 101 to the client 111 on the network by streaming include, for example, a communication link (hereinafter simply referred to as a link) 103, a node (hereinafter referred to as a router) 105 such as a router, a link 107, a router 109,. . . The client 111 is reached via the route.

  When the client 111 receives the packet, the client 111 returns an acknowledgment to the packet to the streaming server 101 as a transmission source. This confirmation response may be performed in the transport layer or in a layer higher than that. The confirmation response may be returned, for example, every time a packet is received, or a plurality of packets may be returned together. Furthermore, a form in which information is organized for a plurality of packets, such as a certain number of packets received from a certain sequence number or a certain number of packets lost in a received stream. You may send it back by. In any case, it is sufficient that the analysis of the cause of the packet loss described later and the response to the cause can have a practically sufficient time response.

  The confirmation response may be returned to the client 111 that is the destination of the data transfer by streaming, or to some relay node in the network 100. For example, but not limited to this, when the client 111 is a mobile terminal such as a mobile phone and the mobile terminal communicates with a radio base station (not shown) connected to the network 100, the streaming server 101 The nature and behavior of the communication line differ between the communication path (usually wired) between the mobile station and the wireless base station and the wireless communication path between the wireless base station and the mobile terminal. It may be more efficient to perform error control. Therefore, in such a configuration, a confirmation response can be returned from the base station to the streaming server 101. Of course, confirmation responses may be returned from both the base station and the mobile terminal.

  The confirmation response may have various implementations as described above and in other respects, but the present invention is not the subject of the configuration / method for the confirmation response. Description is omitted.

  Next, we will explain in detail the two causes of packet loss that can occur when streaming in the above-mentioned form, that is, network congestion and link / node failure, and the difference in the packet loss pattern due to each cause. To do.

  In typical network congestion, packets are lost due to overflows that occur in packet queues in the network router. Most of today's routers employ an algorithm called RED (Random Early Drop) as an algorithm for selecting a packet to be discarded in the packet queue.

  RED will be described with reference to FIG. For example, the router 105 on the network 100 is provided with a packet queue (RED queue) 201 for storing packets arriving at the router 105 until they are sent to an appropriate link, as is well known. It has been. Let the capacity (maximum length) of the RED queue 201 be Hmax. In addition to the stream 203 from the streaming server 101 to the client 111, other packet flows 205 (which may also be streams or other forms of packet flows) also pass through the router 105, these Is flowing into the RED queue 201. Here, if control is performed such that the number of packets h (t) currently in the RED queue 201 is left until the capacity Hmax is reached, and when the RED queue 201 is full, more packets are discarded. There is a possibility that the packet rejection starts, but this causes a disadvantage that an appropriate measure cannot be taken in advance by detecting "signs" of network congestion at the packet destination side. Therefore, in RED, a warning level Hmin smaller than the capacity of the RED queue 201 is set, and when the current number of packets h (t) exceeds the warning level Hmin, a packet newly entering the RED queue 201 Are randomly rejected with a probability proportional to Hmin-h (t). As the RED queue 201 is about to fill up, packets are gradually discarded in this way for all flows coming into the RED queue 201, so packet loss in the flows observed at these flow destinations. There is a very high possibility that the pattern is discontinuous, that is, a pattern in which packets lost in the flow are distributed in a scattered manner.

Refer to the following Non-Patent Document 3 for a more detailed explanation of RED.
S. Floyd, V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance," IEEE / ACM Transactions on Networking, vol.1 no.4, August 1993, p.397-413

  Even if a packet discard algorithm different from RED is adopted, it is generally preferable to avoid a situation in which packets in a flow are continuously lost during network congestion. Algorithms are usually employed where the packet loss patterns that occur are also very likely to be discontinuous.

On the other hand, in the case of a link / node failure, network performance degradation takes the following two stages.
(1) Blocking stage: First, all the packets that are being transmitted on the failed link or node or that are sent to the destination until the failure is detected and the destination is switched are lost.
(2) Routing loop stage: In the process of reconfiguring the routing table in other nodes to avoid the failed link or node, in the routing loop caused by mismatch between these routing tables Packets may get in. Packets whose TTL (Time To Live) exceeds the set value due to the addition of an extra hop by entering the routing loop are lost. Packets that enter the routing loop but get out of it and reach the destination in TTL also have a greater delay than usual.

  The period of the blocking stage is typically about 1 to 2 seconds. That is, from the client, continuous, that is, burst-like packet loss of about 1 to 2 seconds is observed corresponding to the link / node failure blocking stage. Thereafter, the routing table is reconfigured at each node. During this transient state, there is a high possibility that the packet loss rate and the packet delay time will increase compared to before the occurrence of the link node failure.

  As mentioned above, each packet loss pattern due to two causes of network performance degradation is clearly different, so if the packet loss pattern is observed during a streaming session, the network performance degradation currently observed will eventually You can identify what is happening due to.

  FIG. 3 is a flowchart showing a procedure of network congestion / link / node failure control performed by the streaming server 101 of the network of FIG.

  In block 301 in the flowchart of FIG. 3, when the streaming server 101 starts transmitting a stream to the client 111, a process of continuously collecting network statistical information for the past T seconds regarding the stream is started. Here, the network statistical information is an average value of an average packet loss rate, an average value of round trip time, and a variance used as parameters for standard network congestion control performed using the above-described equation (1). That is. The time T is based on the nature and usage status of the target network and the statistical data so far, and these parameters have sufficient stability to perform congestion control using Equation (1) and the situation. It is set to a value that has responsiveness that can respond to changes in. Block 301 further initiates congestion control. The congestion control started here may be, for example, congestion control based on the above-described equation (1). It should be noted that at the beginning of congestion control, sufficiently accurate values of necessary parameters are often unknown, but in such cases, for example, the same streaming transfer in the past or recently performed on the network 100 Parameters obtained during streaming transfer can be used as initial values.

  Next, in block 303, the current network statistical information is saved.

  While the stream is being sent from the server 101 to the client 111, an acknowledgment response to the arrival of the packet constituting the stream is continuously sent back from the client 111 to the server. In block 305, it is checked whether n or more consecutive packet losses have been detected from this acknowledgment, that is, whether a link / node failure has occurred. As a specific method for checking whether or not there are n or more consecutive packet losses, for example, by including the sequence number of the received packet in the confirmation response, adjacent sequence numbers in a series of confirmation responses It is only necessary to detect that has changed by (n + 1) or more. Alternatively, if an acknowledgment for the packet does not arrive for a certain period of time after sending out the packet, it is determined that the packet has not arrived at the client 111, or the client 111 has not received a packet to arrive next for a predetermined period. The client 111 can determine that the packet has been lost and return a response indicating that the packet has not arrived to the server. It is also possible for the client 111 side to detect that consecutive n packet losses have occurred and return the result to the server 101. Note that n may be set to a value that can identify network congestion and link / node failure with the required accuracy based on the properties of the specific target network and the statistical data so far. In addition, the predetermined time in the timeout process can be set similarly. Further, not only a completely continuous packet loss but also a substantially continuous packet loss such as a loss of 9 of 10 consecutive packets can be treated as a continuous packet loss.

  When block 305 confirms n or more consecutive packet losses, first, in block 307, the network statistical information previously saved (block 303) is updated by congestion control (started by block 301). Set to use instead. Thereby, the network statistical information viewed from the congestion control is fixed to the state immediately before the occurrence of the link / node failure. Therefore, while the network performance is deteriorated due to the link / node failure, that is, until the failure is recovered after the determination result in block 305 becomes YES (see the description of block 311), the network congestion control is performed. Is performed based not on the latest network statistical information but on statistical information immediately before the occurrence of the current link / node failure.

  Next, in block 309, processing for improving the error correction capability is started while maintaining the band used for sending the stream. Examples of this process include adding an error correction code, switching to an error correction code having a higher correction capability than an error correction code used in a normal state, and retransmitting a lost packet. The degradation of network performance during the routing loop stage is not improved by reducing the rate of the stream to be sent, but it is received by the client during this time by performing the error correction capability improvement process described here. Stream quality is improved.

  In this process, if a part of the band that has been used for the transmission of the stream is allocated for the error correction code or the retransmission packet, the band of the data such as video and audio in the stream itself decreases. Even in this case, the bandwidth used for the entire stream is considered to be maintained. If the situation permits, the bandwidth used by the data itself may be maintained as it is, and a separate bandwidth may be secured for error correction.

  Note that the processing of block 309 is not necessarily required. In other words, even if the block 309 is omitted, the received stream quality during the routing loop stage in order to perform an improper process of reducing the stream transmission rate by misidentifying a link / node failure as a result of network congestion. This eliminates the disadvantage of the prior art that it is further reduced compared to the case where no processing is performed.

  Next, at block 311, it is determined whether the link / node failure has been recovered. Specifically, determine whether recent values of network statistics have stabilized (that is, whether changes in values have become smaller and need not be the same as before the failure, but have converged to steady values) However, if it is determined that it has stabilized, it is determined that the routing loop stage has ended, that is, it has recovered from the link node failure state. More specifically, whether or not the network statistical information has been stabilized is determined by, for example, checking whether the dispersion of the packet loss rate and the round trip time has converged within a predetermined multiple of the respective averages. be able to.

  When it is determined in block 311 that the link / node has recovered from the failure, the error correction capability improvement processing (started in block 309) is terminated in block 313 and the current network statistics information is saved instead of the saved network statistical information. Set so that the network statistics information is supplied to the congestion control, and return to block 303.

  If n or more consecutive packet losses are not detected in block 305, control returns to 303 and the congestion process continues to use the current network statistics. Accordingly, when the network performance is degraded due to network congestion rather than a link / node failure, an appropriate countermeasure is taken in response to the congestion control reducing the stream transmission rate.

  As described above, according to the present invention, when the network performance is deteriorated, the cause is determined by a simple configuration / procedure, and the corresponding action is taken to minimize the deterioration of the streaming quality. Can do.

  Therefore, it is very beneficial to apply the present invention to congestion control in streaming over a network.

The figure explaining the network to which this invention is applied. The figure explaining the network to which this invention is applied. The flowchart explaining one Example of this invention.

Explanation of symbols

100: network 101: streaming server 103: link 105: router 107: link 109: router 111: client 201: RED queue 203: stream 205: flow 207: packet 209: packet

Claims (14)

A link / node failure occurs when a bursty packet loss occurs in the stream sent by streaming from the streaming server to the client via the network before reaching the client or a predetermined node on the network. A method for determining the cause of network performance degradation that is determined to have occurred. The network performance deterioration cause determination method according to claim 1, wherein it is determined that the burst packet loss has occurred when a predetermined number of consecutive packets in the stream are lost. 3. The network performance deterioration cause determination method according to claim 1, wherein determination of the link / node failure is prioritized over determination of network congestion. The network performance deterioration cause determination method according to claim 3, wherein it is determined that the network congestion has occurred when a packet loss rate and / or a land trip time has increased. The determination according to claim 1, wherein, after it is determined that the link / node failure has occurred, it is determined that the link / node failure has been recovered when it is determined that statistical information regarding the performance of the network has stabilized. The network performance deterioration cause determination method according to any one of the above. 6. The network performance deterioration cause determination method according to claim 5, wherein the statistical information related to the network performance includes a packet loss rate or a round trip time. The network performance deterioration cause determination method according to claim 1, wherein the network is an IP network. A link / node failure occurs when a bursty packet loss occurs in the stream sent by streaming from the streaming server to the client via the network before reaching the client or a predetermined node on the network. Determine that it occurred,
When it is determined that network congestion has occurred while the link / node failure has not occurred, a process of reducing the transmission rate of the stream from the streaming server is executed,
A congestion control method that does not execute a process of reducing the transmission rate of the stream when it is determined that the link / node failure has occurred. The congestion control method according to claim 8, wherein when it is determined that the link / node failure has occurred, a process for increasing an error recovery capability of the stream is performed. The congestion control method according to claim 7, wherein the process for increasing the error recovery capability is any one of use of an error correction code, use of an error correction code having higher error correction capability than normal use, and retransmission of a lost packet. . The congestion control method according to claim 8, wherein it is determined that the burst-like packet loss has occurred when a predetermined number of consecutive packets in the stream are lost. The congestion control method according to claim 8, wherein the network congestion is determined to occur when a packet loss rate and / or a land trip time increases. 13. It is determined that the link / node failure has been recovered when it is determined that statistical information regarding the performance of the network has stabilized after it is determined that the link / node failure has occurred. The congestion control method according to any one of the above. The congestion control method according to claim 13, wherein the statistical information regarding the performance of the network includes a packet loss rate or a round trip time.

Images