본 발명은 TCP의 흐름제어 및 혼잡제어 방법에 관한 것으로서, 특히 전송 계층(Layer 4)의 연결에서 전송중인 세그먼트의 수, 즉 소스(source)를 떠났지만 아직 리시버(receiver)에 도달하지 않은 세그먼트의 수가 많을 경우 이를 네트워크의 버퍼에 전송을 대기하는 세그먼트가 많다는 것으로 인식하여 혼잡 상황으로 해석하고 큐 모델의 이용률과 큐에서 기다리는 패킷의 개수간의 함수 관계를 통해 혼잡 상황의 정도에 따라 현재의 전송률을 변화시키는 방법에 관한 것이다.The present invention relates to a flow control method and a congestion control method of TCP. In particular, the number of segments being transmitted in a connection of a transport layer (Layer 4), that is, the number of segments that have left a source but have not yet reached a receiver. In many cases, it is recognized that there are many segments waiting for transmission in the buffer of the network, and it is interpreted as a congestion situation. It is about a method.
현재 여러 TCP 버전 중에서 많이 사용되고 있는 Reno는 세그먼트가 손실되었다고 판단될 경우에만 혼잡 상황으로 인식하고 혼잡 윈도우(이하, CWND)의 크기를 일정 비율만큼 줄이는 방법을 사용함으로써, 가용대역폭이 큰 폭으로 변할 경우 제대로 적응을 하지 못하는 단점을 지니고 있다. 이는 최근 인터넷과 같이 트래픽이 폭발적으로 증가하고 다양한 멀티미디어 데이터가 혼재하여 가용대역폭의 변화가 심한 고속의 링크 및 단순 에러에 의해 패킷 손실이 야기되는 무선 링크에서는 치명적인 TCP의 성능 저하 요인이 될 수 있다.Reno, which is widely used among several versions of TCP, recognizes congestion only when it is determined that a segment is lost and reduces the size of the congestion window (hereinafter referred to as CWND) by a certain ratio. It has the disadvantage of not adapting properly. This is a fatal TCP performance deterioration factor in the high-speed link with the explosive increase in traffic and various multimedia data such as the Internet, and the packet loss caused by the simple link error.
최근에 등장한 TCP 버전인 Vegas에서는 혼잡 상황을 파악하는 메커니즘으로 종단간의 경로 상에서 전송중인 패킷의 수를 파악하는 방법을 처음 제안하였다. Vegas는 RTT(Round Trip Time)마다 전송중인 패킷의 수를 계산하여 이 값이 기준값보다 작은 경우 CWND의 크기를 한 세그먼트 크기만큼 증가시키고, 큰 경우에는 한 세그먼트 크기만큼 감소시켜, 네트워크의 가용대역폭을 효율적으로 사용하고 혼잡 상황에 적절히 대응한다.In the recent TCP version of Vegas, Vegas first proposed a method of detecting the number of packets being transmitted on the end-to-end path as a mechanism for detecting congestion. Vegas calculates the number of packets being sent per round trip time (RTT) and increases the CWND size by one segment size if this value is less than the reference value, and decreases the size of the available bandwidth of the network by one segment size if it is large. Use efficiently and respond appropriately to congestion situations.
즉, Vegas는 TCP의 소스에서 가용대역폭 이상의 전송률로 세그먼트를 보낼 경우 여분의 대역폭이 없기 때문에 링크 내에는 존재하지만 전송이 되지 않은 세그먼트의 양을 측정하여 혼잡 상태 여부를 판단하고 이를 제어한다. 이러한 세그먼트의 양을 잉여 데이터(Extra Data)라고 정의한다. TCP가 가용대역폭을 모두 사용하지 않으면 잉여 데이터는 존재하지 않는다.In other words, when a segment of a TCP is sent at a bit rate higher than the available bandwidth, Vegas determines whether there is congestion by measuring the amount of segments present in the link but not transmitted because there is no extra bandwidth. The amount of such segments is defined as extra data. If TCP does not use all the available bandwidth, there is no surplus data.
TCP Vegas를 사용하는 소스에서는 연결 상황을 직접 볼 수 없기 때문에 CWND의 크기와 계산된 RTT를 통해 간접적으로 잉여 데이터를 예측하고 미리 정해진 기준값과 비교함으로써 CWND 크기의 증감여부를 결정한다. 즉, 잉여 데이터가 기준값보다 클 경우에는 혼잡 상황이 발생할 가능성이 높은 것으로 해석하여 CWND의 크기를 줄이고 기준값보다 작은 경우에는 대역폭에 여유가 있다고 판단하여 증가시킨다.Sources using TCP Vegas cannot see the connection directly, so the CWND size and calculated RTT indirectly predict surplus data and compare it with a predetermined reference value to determine whether the CWND size will increase or decrease. In other words, if excess data is larger than the reference value, congestion is likely to occur, and the size of CWND is reduced, and if it is smaller than the reference value, the bandwidth is determined to be increased.
연결(connection) 링크의 상황을 예측하기 위하여 연결 전체를 하나의 커다란 가상의 버퍼로 볼 경우, 잉여 데이터는 그 버퍼에 쌓인 세그먼트의 양으로 생각할 수 있다. 또는 TCP의 소스(source)에서는 위치나 상태를 파악할 수 없을 것으로 생각되는 정체된 링크의 버퍼에 쌓인 데이터의 양을 잉여 데이터로 생각하더라도 무방하다. 그 이유는 정체된 링크이외의 링크에서는 가용대역폭에 여유가 있다고 하더라도 정체된 링크에서는 가용대역폭을 모두 사용했기 때문에 자연히 버퍼에 데이터가 쌓이기 때문이다. Vegas는 이와 같이 연결 링크의 상황을 예측하는 잉여 데이터를 산출하여 전송률을 제어하는 CWND를 조절함으로써 혼잡 상황을 피하고 있다.If you look at the entire connection as one large virtual buffer to predict the link's situation, the surplus data can be thought of as the amount of segments accumulated in that buffer. Alternatively, the amount of data accumulated in the buffer of the congested link, which may not be known at the source of the TCP, may be considered as redundant data. The reason is that even though there is room in the available bandwidth on the link other than the congested link, the data naturally accumulates in the buffer because the available bandwidth is used on the congested link. Vegas avoids congestion by adjusting CWND, which controls the data rate, by calculating surplus data to predict the condition of the link.
Vegas에서 사용하는 알고리즘에 대하여 상세히 설명하면 다음과 같다. Vegas는 단위 시간동안 연결 링크에 존재하는 세그먼트의 양에서 연결의 가용대역폭이 처리할 수 있는 세그먼트의 양을 뺌으로써 잉여 데이터를 구하는데 이 과정에서 기대 처리율(Expected Throughput)과 실제 처리율(Actual Throughput)을 이용한다.The algorithm used in Vegas is explained in detail as follows. Vegas obtains surplus data by subtracting the amount of segments that the connection's available bandwidth can process from the amount of segments in the connection link for a unit of time. In this process, expected throughput and actual throughput are calculated. Use
중간 노드 버퍼에 데이터가 쌓여 있지 않을 경우 전송된 세그먼트에 의한 RTT를 최소 RTT(Base RTT)라 정의하는데, 실제 구현에서는 측정된 최소값의 RTT를 의미한다. 이때 잉여 데이터가 발생하지 않고 최소 RTT 동안 CWND 크기만큼 전송하는 경우 기대되는 전송률을 기대 처리율이라고 하고 측정된 RTT마다 어느 정도의 데이터가 전송되었는지를 실제 처리율로 정의한다.If data is not accumulated in the intermediate node buffer, the RTT of the transmitted segment is defined as a minimum RTT (Base RTT). In an actual implementation, it means an RTT of the measured minimum value. In this case, when the CWND size is transmitted during the minimum RTT without surplus data, the expected throughput is referred to as expected throughput, and the actual throughput is defined as how much data is transmitted for each measured RTT.
기대 처리율 = CWND의 크기 / 최소 RTT---(1)Expected throughput = size of CWND / min RTT --- (1)
실제 처리율 = 전송중인 데이터 / RTT---(2)Actual throughput = data being transmitted / RTT --- (2)
이 두 값을 이용하면 실제 소스에서 네트워크로 전송한 데이터는 (기대 처리율 ×최소 RTT)이지만, 기본적으로 최소 RTT 동안 정체된 링크에서 처리할 수 있는 양은 (실제 처리율 ×최소 RTT)이기 때문에 소스에서 추측할 수 있는 잉여 데이터는 다음과 같이 표시된다.Using these two values, the data sent from the real source to the network is (Expected Throughput × Least RTT), but basically the amount that can be handled by the congested link during the Minimum RTT is (Actual Throughput × Least RTT), which is assumed by the source. The surplus data that can be displayed is shown as follows.
δ= (기대 처리율 - 실제 처리율) ×최소 RTT---(3)δ = (expected throughput-actual throughput) × minimum RTT --- (3)
실제 TCP에서는 보통 데이터를 CWND 크기의 기본단위인 세그먼트로 전송하기 때문에 CWND와 전송중인 데이터의 단위는 세그먼트로 한다. 그러므로 식(3)의 δ에 대한 기본 단위 역시 세그먼트이다. 만일 (실제 처리율 > 기대 처리율)이라면 측정된 RTT가 최소 RTT보다 작음을 나타내므로 최소 RTT는 갱신된다.In general, TCP transmits data in segments, which are the basic units of CWND size, so the units of CWND and data being transmitted are segments. Therefore, the basic unit for δ in equation (3) is also a segment. If (actual throughput> expected throughput) indicates that the measured RTT is less than the minimum RTT, then the minimum RTT is updated.
마지막으로 잉여 데이터로 연결 상황을 예측하여 CWND의 크기를 증가, 감소, 및 고정시키는 기준을 정한다. 이를 위하여 CWND의 크기를 고정시키는 제어는 목표 잉여 데이터를 적절한 영역으로 설정함으로써 CWND의 크기의 불필요한 증감을 막고 안정된 제어가 가능하도록 한다. 영역의 경계로서 α< β인 α와 β를 설정한다면 α≤δ≤β인 경우는 잉여 데이터가 적당한 때, α〉δ는 잉여 데이터가 적을 때, δ〉β는 잉여 데이터가 많을 때를 의미한다. 일반적인 TCP Vegas에서는 α= 1, β = 3을 흔히 사용하고 있으며 그 이후의 제어는 매 RTT마다 아래와 같은 방식으로 이루어진다.Finally, redundant data is used to predict the linkage situation, setting criteria for increasing, decreasing, and fixing the size of the CWND. For this purpose, the control of fixing the size of the CWND sets the target surplus data to an appropriate area to prevent unnecessary increase and decrease of the size of the CWND and to enable stable control. If α and β are set as the boundary of the region, if α≤δ≤β, the excess data is appropriate, α> δ is small, and δ> β is large. . In general TCP Vegas, α = 1 and β = 3 are commonly used, and subsequent control is performed in each RTT as follows.
---(4) --- (4)
위 식에서 CWNDcurrent는 현재 측정된 CWND의 크기이며 CWNDnew는 제어 후에 적용되는 CWND의 크기이다. 결국 TCP Vegas의 소스에서 계산된 잉여 데이터를 안정 영역인 α와 β의 사이에 놓기 위한 수단으로 CWND의 크기를 단위 세그먼트만큼 늘이거나 줄이는 방법을 사용함으로써 변화하는 연결 상황에 맞추어 알맞은 잉여 데이터를 유지하고 연결의 가용대역폭을 충분히 활용하게 된다. 이는 혼잡 상황을 제어할 때 미리 네트워크의 상황을 예측하고 CWND의 크기를 변화시키는 것으로서 Reno에 의해 버퍼 오버플로우나 타임아웃을 감소시켜 보다 나은 성능을 유도한다.In the above equation, CWNDcurrent is the magnitude of CWND currently measured and CWNDnew is the magnitude of CWND applied after control. Eventually, the surplus data calculated from the source of TCP Vegas is placed between α and β, which are stable areas, to increase or decrease the size of CWND by unit segment to maintain the surplus data appropriate for changing connection conditions. It takes full advantage of the available bandwidth of the connection. This predicts the network situation in advance when controlling the congestion situation and changes the size of CWND, which leads to better performance by reducing buffer overflow or timeout by Reno.
도 1은 TCP 연결을 버퍼(10)로 비유하였을 때 Vegas에서 수행하는 혼잡 제어 방법을 나타낸다. 소스의 전송률이 정체된 링크의 가용대역폭에 해당하는 버퍼의 처리율보다 높은 경우 발생하는 잉여 데이터에 대하여 매 RTT마다 CWND의 크기를 증감하거나, 고정시키는 제어를 수행한다.1 illustrates a congestion control method performed in Vegas when the TCP connection is compared to the buffer 10. If the transmission rate of the source is higher than the throughput of the buffer corresponding to the available bandwidth of the congested link, control is performed to increase or decrease the size of CWND for every RTT.
그러나 TCP Vegas는 매 RTT마다 데이터의 크기를 안정 영역인 α와 β의 사이에 놓기 위해 단위 세그먼트만큼 CWND의 크기를 증감시키지만 변화하는 크기가 세그먼트 한 개의 크기로 제한되므로, 고속의 링크에서 가용한 대역폭의 변화가 클 경우 잘 적응하지 못하는 문제가 있다. 따라서 CWND의 크기를 증가시킬 때에는 비효율적인 대역폭의 사용이 문제되며, 감소시킬 때에는 버퍼 오버플로우가 느리거나 타임아웃과 같은 치명적인 약점을 나타낸다. 이와 같이 TCP Vegas는 가용한 대역폭의 변화가 큰 경우에 일반적으로 잘 적응하지 못하는 문제가 있다.However, TCP Vegas increases or decreases the size of CWND by a unit segment in order to put the size of data between the stable areas α and β at every RTT, but the changing size is limited to the size of one segment. If the change is large, there is a problem of not adapting well. Therefore, increasing the size of the CWND is an inefficient use of bandwidth, and when reducing the CWND, the buffer overflow is slow or represents a fatal weakness such as a timeout. As such, TCP Vegas generally does not adapt well when the available bandwidth change is large.
본 발명은 이러한 종래 기술의 문제를 해결하고자 종단간 패킷 전송과 이에 대한 응답인 ACK로 연결에 대한 정보를 도출하여 혼잡 상황을 추측함과 동시에 TCP에서 바라본 네트워크에 해당하는 연결에 큐 모델을 적용함으로써 혼잡 상황의 정도에 따라 현재의 전송률에서 변경할 양을 바로 결정함으로써 가용대역폭에 이르는 수렴 속도를 향상시켜 데이터의 손실로 인한 성능 저하 가능성을 낮춤으로써 안정된 제어가 가능하도록 하는 것을 목적으로 한다.The present invention derives information about the connection by end-to-end packet transmission and ACK as a response to solve the problems of the prior art, infers congestion, and simultaneously applies a queue model to the connection corresponding to the network seen by TCP. It aims to enable stable control by reducing the possibility of performance degradation due to data loss by improving the convergence speed to the available bandwidth by immediately determining the amount to be changed in the current transmission rate according to the degree of congestion.
본 발명에 의한 네트워크의 혼잡 제어 방법은 소스에서 바라본 TCP 연결을 가상의 버퍼를 이용하여 큐 모델로 표현하는 단계, 소스에서 계산된 잉여 데이터 값을 큐 모델에 쌓인 패킷의 양과 일치시켜 이용률을 구하는 단계, 이용률의 값과 목표 이용률의 차이에 비례하도록 혼잡 윈도우 크기의 변화량을 결정하는 단계, 및 결정된 변화량을 이용하여 혼잡 윈도우의 크기를 변경시키는 단계를 포함한다.The congestion control method of the network according to the present invention comprises expressing a TCP connection viewed from a source into a queue model using a virtual buffer, and calculating a utilization rate by matching surplus data values calculated at the source with the amount of packets accumulated in the queue model. Determining a change amount of the congestion window size to be proportional to a difference between the value of the utilization rate and the target utilization rate, and changing the size of the congestion window using the determined change amount.
본 발명은 TCP Vegas의 잉여 데이터가 정체된 링크의 버퍼에 쌓인 데이터와 일치한다고 가정하고 TCP에서 바라본 네트워크에 해당하는 연결을 하나의 커다란 가상의 버퍼로 가정하고 전체 네트워크가 아닌 TCP에서 바라본 네트워크에 해당하는 연결을 큐로 모델링한다.The present invention assumes that the excess data of TCP Vegas matches the data accumulated in the buffer of the congested link, and assumes that the network corresponding to the TCP is viewed as one large virtual buffer. Model the connection as a queue.
큐에서는 일반적으로 패킷에 대한 서비스 시간(Ts)이 일정할 경우 이용률(ρ)이 패킷 도착률(λ)과 비례하고 패킷 도착률(λ)이 증가함에 따라 큐에 쌓이는 패킷의 양(w)은 지수형태로 증가하게 되는 특성을 지닌다.In queues, when the service time (Ts) for a packet is constant, the utilization rate (ρ) is proportional to the packet arrival rate (λ), and the amount of packets accumulated in the queue (w) increases as the packet arrival rate (λ) increases. It has the property to increase.
그러므로 현재의 패킷 도착률이 λcurrent일 때 목표로 하는 큐에 쌓이는 패킷의 양(wtarget)이 있다면 그에 해당하는 목표 패킷 도착률(λtarget)은 Ts가 일정하다는 사실로부터 다음과 같이 표현할 수 있다.Therefore, if the amount of the current packet arrival rate is accumulated in the queue of the target when thecurrent packet λ (wtarget) target packet arrival rate (λtarget) corresponding thereto may be expressed as follows from the fact that Ts is constant.
ρ = λ Ts (모든 ρ에 대해)---(5)ρ = λ Ts (for all ρ) --- (5)
---(6) --- (6)
---(7) --- (7)
이를 이용하여 목표 전송률과 현재의 전송률 사이의 오차를 알 수 있으며 목표로 하는 잉여 데이터의 양에 도달하기 위한 윈도우 변화량을 직접 구할 수 있다. 이로써 네트워크 상황에 보다 빨리 반응하여 연결에 주어진 대역폭을 보다 효율적으로 관리할 수 있게 하며 연결 링크의 외부 트래픽으로 인한 가용대역폭이 급변하더라도 목표 잉여 데이터에 빨리 수렴시킴으로써 혼잡 상황으로 야기되는 성능 저하를 유연하게 방지할 수 있게 된다.By using this, the error between the target data rate and the current data rate can be known, and the window change amount for reaching the target amount of surplus data can be directly obtained. This allows you to react more quickly to network conditions and more efficiently manage the bandwidth given to the connection, and to flexibly converge to the target surplus data, even if the available bandwidth due to external traffic on the connection link changes rapidly, to flexibly reduce the performance degradation caused by congestion. It can be prevented.
이하에서는 첨부한 도면을 참조하여 본 발명의 실시예에 대하여 상세히 설명한다.Hereinafter, with reference to the accompanying drawings will be described in detail an embodiment of the present invention.
도 2는 본 발명에서 제시하는 큐 모델의 전송률(λ)과 큐에 쌓이는 패킷의 개수(w)에 관한 관계를 나타낸 그래프이다. 실제 연결에서 목표로 하는 잉여 데이터는 큐에 쌓이는 패킷의 개수로 볼 수 있다. 따라서 목표값에 도달하기 위한 전송률의 변화량은 Δλ이다.2 is a graph showing the relationship between the transmission rate (λ) of the queue model proposed in the present invention and the number (w) of packets accumulated in the queue. The surplus data targeted by the actual connection can be seen as the number of packets accumulated in the queue. Therefore, the amount of change in the transmission rate to reach the target value is Δλ.
본 실시예에서는 TCP 연결을 모델링하기 위해서 TCP의 특성에 보다 잘 어울리는 M/D/1 큐 모델을 이용한다. M/D/1 큐 모델에는 다음과 같은 장점이 있다.In this embodiment, in order to model a TCP connection, an M / D / 1 queue model that better suits the characteristics of TCP is used. The M / D / 1 cue model has the following advantages:
첫째, 비록 TCP가 매 RTT마다 전송률의 변화가 심한 특성을 나타내고 있지만 고속의 다양한 트래픽이 존재하는 상황이라면 TCP 연결의 정체된 링크에는 입력 트래픽으로 가장 많이 사용되는 포와송 분포(Poisson Distribution)를 가정할 수 있다.First, although TCP has a high rate of change in every RTT, if there is a variety of high-speed traffic, it is assumed that Poisson Distribution, which is the most used as input traffic, is used for congested links of TCP connections. Can be.
둘째, 대부분의 경우 연결의 TCP 세그먼트의 크기가 고정되어 있어서 전송하는 기본단위가 일정하기 때문에 서비스 시간은 일정하다고 볼 수 있다.Second, in most cases, the service time is constant because the size of the TCP segment of the connection is fixed and the basic unit of transmission is constant.
셋째, 정체된 링크의 버퍼를 TCP에서 바라본 네트워크에 해당하는 가상의 버퍼로 해석했기 때문에 서버의 개수는 하나로 한다.Third, because the buffer of the congested link is interpreted as a virtual buffer corresponding to the network seen by TCP, the number of servers is one.
이와 같은 특성에도 불구하고 정확한 예측이 불확실한 TCP 연결을 완벽한 M/D/1 큐 모델의 환경에 맞출 수는 없다. 그러나 M/D/1 큐 모델은 매 RTT마다 변화시킬 CWND의 크기를 결정할 수 있는 λ에 대한 w의 함수 관계를 제공하는 장점이 있다.Despite these characteristics, TCP connections with uncertain predictions cannot be adapted to the environment of a complete M / D / 1 queue model. However, the M / D / 1 cue model has the advantage of providing a functional relationship of w to λ that can determine the magnitude of CWND to change for every RTT.
TCP Vegas의 잉여 데이터에 해당하는 양은 M/D/1 큐 모델의 w로 표현될 수 있고, 이때의 w 값에 대응하는 ρ값은 Little's Law의 일반식들을 통해 찾을 수 있다. M/D/1 큐 모델에 Little's Law를 적용시키면 식(8)과 같이 λ에 대한 w의 관계를 도출할 수 있고, 잉여 데이터(δ)와 w를 같게 보므로 식(3)을 적용하면 식(9)과 같은 관계를 얻을 수 있다.The amount corresponding to the excess data of TCP Vegas may be represented by w of the M / D / 1 queue model, and the p value corresponding to the w value at this time may be found through general formulas of Little's Law. Applying Little's Law to the M / D / 1 cue model, we can derive the relationship of w to λ as shown in Eq. (8). The relationship as shown in (9) can be obtained.
---(8) --- (8)
---(9) --- (9)
식(9)의 ρ는 소스에서 할 수 있는 연결의 상황 판단 및 결정의 지침으로써 얼마만큼의 CWND를 변화시킬 때 목표로 하는 잉여 데이터에 접근하는지를 한 번에 알려 주므로, 대역폭이 변함에 따라 자동적으로 그 양을 조절하는 지능적이고 효율적인 제어가 가능하게 된다.Ρ in Eq. (9) is a guide for judging and determining the status of the connection at the source, and tells you at a time how much CWND changes to target the surplus data at the target. Intelligent and efficient control of the amount is enabled.
식(9)를 통해서 ρcurrent를 구하면 실제 제어되는 CWND의 변화량을 쉽게 유도할 수 있는데, 식(7)을 적용하면 λtarget을 식(10)과 같이 구할 수 있다. 실제로 제어되는 혼잡 윈도우의 변화량(이하, ΔCWND)은 식(11)과 같다.If ρcurrent is obtained through Eq. (9), the change of CWND actually controlled can be easily derived. By applying Eq. (7), λtarget can be obtained as Eq. (10). The amount of change in the congestion window that is actually controlled (hereinafter,? CWND) is shown in equation (11).
--- (10) --- (10)
---(11) --- (11)
이제 매 RTT마다 변화시킬 CWND의 크기를 결정할 수 있다. 그러나 계층화된 네트워크 구조에서 TCP가 현재처럼 기본적인 종단간 전송 방식 제어를 유지한다면 네트워크 정보를 예측하기 힘든 TCP는 이 전송량을 적용하는 데 문제가 있다. 따라서 예측이 힘든 연결 상태를 정확히 판단하기 위한 척도로서 큐 모델을 적용하는 것은 완벽하지 않기 때문에 ρ에 대한 w의 그래프를 적용할 때 다음과 같은 몇 가지 기본적인 파라미터들과 미세한 인자들의 수정이 요구된다.Now we can determine the amount of CWND to change for every RTT. However, if TCP maintains basic end-to-end transmission control in the layered network structure, TCP, which is difficult to predict network information, has a problem in applying this transmission amount. Therefore, applying the cue model as a measure to accurately determine the unpredictable connection state is not perfect, and when applying the graph of w for ρ, some basic parameters and fine factors need to be modified.
첫째, TCP 소스에서 ΔCWND를 네트워크에 입력하였을 때 그에 대한 네트워크의 영향을 나타내는 측정된 RTT 값은 약간씩 지연이 발생하기 때문에 이용률은 ρtarget에 고정되지 않고 진동을 일으켜 ΔCWND에서도 진동이 발생한다. 이러한 불안정 요소를 제거하고자 TCP Vegas와 마찬가지로 측정된 이용률이 일정 구간에 위치할 경우에 CWND의 크기에 변화를 주지 않음으로써 진동을 없애는 방식을 적용한다. 이때 적용되는 안정영역의 경계는 Vegas와의 비교를 위해 일반적인 TCP Vegas의 α와 β(α=1, β= 3)에 해당하는 이용률을 사용하며 목표로 하는 이용률은 이 두 값의 중간값인 (α+β)/2를 사용한다. 식(8), (9)를 이용하여 α에 해당하는 이용률(ρα), β에 해당하는 이용률(ρβ), (α+β)/2에 해당하는 이용률 (ρtarget)을 각각 구한다.First, when ΔCWND is input from the TCP source into the network, the measured RTT value indicating the network's effect on the network is slightly delayed. Therefore, the utilization rate is not fixed to the ρtarget . Like TCP Vegas, to eliminate this instability, a method of eliminating vibration by not changing the magnitude of CWND when the measured utilization is located in a certain section is applied. At this time, the boundary of the applied stability area uses the utilization rate corresponding to α and β (α = 1, β = 3) of general TCP Vegas for comparison with Vegas, and the target utilization rate is the intermediate value between these two values (α + β) / 2 is used. Using equations (8) and (9), the utilization rate ρα corresponding to α, the utilization rate ρβ corresponding toβ , and the utilization rate ρtarget corresponding to (α + β) / 2 are obtained, respectively.
---(12) --- (12)
둘째, 측정된 잉여 데이터 값이 극히 작은 양이라면 큐 모델에서 ρ에 대한 w의 그래프 특성상 ρ를 구할 때 오차 발생 확률이 커져서 제대로 된 ΔCWND를 구할 수 없을 뿐만 아니라 ρtarget에 이르기 위한 ΔCWND가 너무 커져서 실제 네트워크에 적용될 때 현실성이 떨어진다. 그래서 ΔCWND량을 구할 때 적용할 ρcurrent의 최소값을 설정하여 측정된 ρ값이 그보다 작더라도 안정된 제어가 가능하도록 했다. 여기에서는 ρcurrent의 최소값으로 w=0.604에 해당하는 0.65를 사용한다. 도 3은 TCP Vegas의 잉여 데이터에 대응하는 수정된 큐 모델의 TCP 알고리즘에서 보이는 ρ에 대한 w의 곡선을 나타낸다.Second, if the measured excess data value extremely small amounts as well as the absence of the error probability can get ΔCWND a large, well you get the w graph characteristic ρ of the ρ in the queue model ΔCWND to attain ρtarget so large real When applied to a network, it is less realistic. Therefore, the minimum value of ρcurrent to be applied when calculating ΔCWND amount is set so that stable control is possible even if the measured value of ρ is smaller than that. In this case, the minimum value of ρcurrent is used as 0.65 corresponding to w = 0.604. 3 shows a curve of w versus p seen in the TCP algorithm of the modified queue model corresponding to surplus data in TCP Vegas.
셋째, ρtarget을 만족시키기 위해 식(11)을 통해서 나온 ΔCWND을 그대로 적용하면 TCP는 전송률의 변화가 심한 특징 때문에 순간적으로 오버플로우나 타임아웃과 같은 성능 저하가 발생할 수 있다. 이는 큐 모델이 실제 TCP에서 바라본 커넥션과 정확히 일치하지 않기 때문이다. 이러한 문제의 해결을 위해서 안전하게 윈도우의 변화율을 큐 모델로부터 얻은 값에서 일정 비율 줄여주고, 또 윈도우의 최대 변화량도 제한을 한다. 식 (13), (14)는 식 (11)의 ΔCWND을 3.5로 나누고 최대 변화량을 ±4로 제한한다. 이 경우에도 기존의 TCP Vegas에서 제시한 ±1보다는 크기 때문에 훨씬 빨리 목표로 하는 잉여 데이터 값에 도달할 수 있다.Third, if ΔCWND from Equation (11) is applied to satisfy the ρtarget , TCP may experience performance degradation such as overflow or timeout in a short time due to the characteristic of high rate change. This is because the queue model does not exactly match the connection seen by TCP. To solve this problem, we safely reduce the rate of change of the window from the value obtained from the queue model and limit the maximum amount of change of the window. Equations (13) and (14) divide ΔCWND in Equation (11) by 3.5 and limit the maximum change to ± 4. Even in this case, the target surplus data value can be reached much faster because it is larger than ± 1 suggested by TCP Vegas.
---(13) --- (13)
---(14) --- (14)
이렇게 TCP 제어의 특성에 맞게 수정한 큐 모델은 실제 정체된 링크가 있는 커넥션에 적용될 때 동적으로 유입되는 외부 트래픽에 의해 가용대역폭이 변하더라도 빠르고 안정적으로 적응한다.This modified queue model adapts to the characteristics of TCP control and adapts quickly and reliably even when the available bandwidth changes due to dynamically flowing external traffic when applied to a connection with a congested link.
다음은 네트워크 시뮬레이션 프로그램인 NS(Network Simulator)-2를 사용하여 본 발명의 성능을 TCP Vegas와 비교 분석한 결과에 관한 것이다.The following is a result of comparing and analyzing the performance of the present invention with TCP Vegas using NS (Network Simulator) -2, a network simulation program.
첫번째 시뮬레이션은 TCP 연결 링크에서 가용대역폭이 급격하게 한 번 바뀌는 경우이다.The first simulation is a case where the available bandwidth changes rapidly once in a TCP connection link.
도 4는 첫번째 시뮬레이션에 대한 네트워크 설정 구조를 나타낸다. 노드 S0은 노드 D0에게 0~30초 동안 FTP를 이용해서 세그먼트의 크기가 1KB인 TCP를 이용하여 큰 파일을 전송하고 노드 S1은 D1에게 10~20s초 동안 UDP를 이용하여 1Mbps의 데이터를 전송한다. 이 때 R1-R2 구간은 4Mbps의 대역폭에 50ms의 전송 지연 시간을 가지며 S0, S1-R1 구간과 R2-D0, D1 구간은 50Mbps에 0s의 전송 지연 시간을 가지는데, 이들 링크는 시뮬레이션 결과에 거의 영향을 미치지 않고 단지 링크를 구분하기 위한 목적으로 사용된다. R1과 R2의 버퍼 크기는 유연한 시뮬레이션 환경을 위해 50KB로 충분히 크게 설정한다.4 shows the network configuration structure for the first simulation. Node S0 sends a large file using TCP with segment size 1KB using FTP for node D0 for 0-30 seconds, and node S1 sends 1Mbps data using UDP for 10-20s seconds for D1. . In this case, the R1-R2 section has a transmission delay time of 50 ms with a bandwidth of 4 Mbps, and the S0, S1-R1 sections, and the R2-D0, D1 sections have a transmission delay time of 0 s at 50 Mbps. It is used only to distinguish links without affecting them. The buffer size of R1 and R2 is set large enough to be 50KB for a flexible simulation environment.
도 5는 링크 R1-R2에 할당된 대역폭인 4Mbps 중에서 0~30s동안 작동중인TCP와 10~20s동안 외부에서 유입된 UDP 트래픽에 설정된 가용대역폭을 보여준다. TCP의 가용대역폭은 외부 UDP 트래픽이 유입된 10~20s에만 3Mbps일 뿐 나머지는 4Mbps를 유지한다.FIG. 5 shows the available bandwidth set for TCP in operation for 0 to 30 s and UDP traffic for 10 to 20 s among 4 Mbps of bandwidth allocated to links R1 to R2. The available bandwidth of TCP is 3Mbps only for 10 ~ 20s when external UDP traffic flows, while remaining 4Mbps.
외부 트래픽이 TCP 커넥션의 중간에 한 번 유입되었다가 나갈 경우 큐 모델을 적용한 TCP와 기존의 TCP Vegas간의 성능 비교를 위해 S0의 CWND 크기와 보내는 방향의 정체된 링크에 해당하는 R1의 버퍼 크기를 확인한다. TCP는 신뢰할 수 있는 서비스를 제공하므로 CWND 크기 자체가 데이터 전송률, 수신율과 같은 성능을 표현한다고 볼 수 있다. 실측된 R1 버퍼 크기의 비교를 통해서 가용대역폭에 대한 실제 잉여 데이터를 알 수 있으므로 혼잡 상황으로 인한 커넥션의 안정도를 객관적으로 확인할 수 있다.When external traffic flows in and out of a TCP connection once, check the CWND size of S0 and the buffer size of R1 corresponding to the congested link in the outgoing direction for performance comparison between TCP with queuing model and conventional TCP Vegas. do. Since TCP provides a reliable service, CWND size itself can represent performance such as data rate and reception rate. By comparing the measured R1 buffer size, the actual surplus data for the available bandwidth can be known, and the stability of the connection due to congestion can be objectively verified.
도 6은 첫번째 시뮬레이션에서 본 발명을 적용한 경우(실선)와 TCP Vegas(점선)를 적용한 경우의 CWND의 크기를 비교한 그래프이다. 세그먼트의 크기가 1KB이므로 R1-R2링크를 혼자 사용하면 가용대역폭을 정확히 활용할 때 두 경우 모두 CWND는 50개의 세그먼트이고, 외부트래픽이 유입되는 10~20s에서는 40개의 세그먼트이다. 이 때 눈여겨봐야 할 세 부분은 가용대역폭이 갑작스레 바뀌는 경우인 1s(연결이 성립되는 순간), 10s(외부 트래픽 유입되는 순간), 20s(외부 트래픽이 다시 빠져나가는 순간)이다. 우선 연결이 성립되는 순간, 즉 1s부터 가용대역폭까지 이르는데 걸리는 시간을 보면 큐 모델을 이용한 TCP가 2.61s, TCP Vegas가 4.16s로 2.54s정도의 큰 차이를 나타낸다. 이는 TCP가 사용할 수 있는 가용대역폭이 많이 남아있을 경우에 본 발명에 따른 큐 모델을 이용한 TCP는 전술한 바와 같이 CWND의 변화량을 신속하게 결정하기 때문에 TCP Vegas에 비해 목표로 하는 잉여 데이터 값으로 빠르게 수렴한다는 사실을 말해준다. 둘째, 10s(외부 트래픽이 유입되는 순간)에 큐 모델을 이용한 TCP는 매 RTT마다 CWND를 하나 이상으로 줄이기 때문에 약 0.72s 빨리 가용대역폭에 수렴한다. 셋째, 20s(외부 트래픽이 빠져나가는 순간)일 때에도 제안된 알고리즘은 매 RTT마다 CWND의 변화량을 1보다 크게 함으로써 Vegas에 비해 약 0.79s 빨리 올라간다.6 is a graph comparing CWND sizes when the present invention is applied in the first simulation (solid line) and when TCP Vegas (dotted line) is applied. Since the size of the segment is 1KB, when the R1-R2 link alone is used, CWND is 50 segments in both cases, and 40 segments in 10 ~ 20s when external traffic flows. The three things to watch for are the sudden change in available bandwidth: 1s (when a connection is established), 10s (when external traffic comes in), and 20s (when external traffic comes out again). First, when the connection is established, that is, the time taken from 1s to the available bandwidth, the TCP difference is 2.61s using the queue model and the TCP Vegas is 4.16s. This is because when the available bandwidth available for TCP remains, TCP using the queue model according to the present invention quickly determines the amount of change in CWND as described above, so that it converges quickly to the target surplus data value compared to TCP Vegas. Tell them you do. Second, TCP using the queue model at 10 s (the moment that external traffic comes in) reduces convergence to available bandwidth by about 0.72 s because it reduces one or more CWNDs for every RTT. Third, even in the case of 20s (the moment that the external traffic escapes), the proposed algorithm is about 0.79s faster than Vegas by making the CWND change greater than 1 for every RTT.
도 7a 및 도 7b는 각각 본 발명에 의한 경우와 TCP Vegas를 적용한 경우의 R1의 버퍼를 나타내는 그래프이다. 큐 모델을 이용한 TCP는 매 RTT마다 CWND를 하나 이상으로 줄이기 때문에 매 RTT마다 하나씩 CWND를 줄이는Vegas에 비해 훨씬 신속하게 CWND를 감소시켜 가용대역폭에 빨리 수렴함을 알 수 있다.7A and 7B are graphs showing buffers of R1 according to the present invention and TCP Vegas, respectively. TCP using the queuing model reduces CWND to more than one for every RTT, so it can be seen that it quickly converges to the available bandwidth by reducing CWND much faster than Vegas, which reduces CWND by one for every RTT.
두번째 시뮬레이션은 TCP 커넥션 링크에서 가용대역폭이 짧은 시간 간격으로 수차례 바뀌는 경우이다.The second simulation is a case where the available bandwidth changes several times in short time intervals on a TCP connection link.
도 8은 두번째 시뮬레이션을 위한 네트워크 설정 구조를 보여준다. 짧은 시간동안 지속적으로 변화하는 외부 트래픽에 적응하는 TCP의 성능을 비교하기 위해외부 트래픽을 S1~S4에서 R1~R4로 500Kbps UDP를 네 번에 걸쳐 계단 형태로 10~21.5s 동안 인가한다.8 shows the network configuration structure for the second simulation. To compare the performance of TCP adapting to constantly changing external traffic over a short period of time. Apply 500Kbps UDP for 10 ~ 21.5s in stair form four times from S1 ~ S4 to R1 ~ R4.
도 9는 링크 R1 ~ R2에 할당된 대역폭인 4Mbps 중에서 0~30초 동안 작동중인 TCP와 10~20초 동안 외부에서 유입된 UDP 트래픽에 설정된 가용대역폭을 보여준다. TCP의 가용대역폭은 외부 UDP 트래픽이 유입된 10~21.5초에 계단 모양으로 변화하고 나머지는 4Mbps를 유지한다.FIG. 9 shows the available bandwidth set for TCP in operation for 0 to 30 seconds and UDP traffic introduced from outside for 10 to 20 seconds among 4 Mbps which are bandwidths allocated to links R1 to R2. The available bandwidth of TCP changes in a step shape between 10 and 21.5 seconds when external UDP traffic flows, and the rest is maintained at 4 Mbps.
도 10은 본 발명에 의한 큐 모델을 적용한 TCP(실선)와 종래의 TCP Vegas에서의 혼잡 윈도우의 크기를 비교한 그래프이다. 그래프에 표시된 바와 같이 큐 모델을 적용한 TCP는 외부트래픽이 짧은 간격으로 계속 유입되더라도 꾸준하게 적응을 해나가고 있지만 TCP Vegas는 타임아웃이 발생해서 결국에는 CWND가 초기값인 1까지 감소함을 알 수 있다. 이는 매 RTT마다 하나의 세그먼트에 해당하는 크기의 CWND를 증감시키는 방법을 적용하는 TCP Vegas가 순간적으로 크게 변화되는 가용대역폭의 변화에는 제대로 적응하지 못하기 때문이다.10 is a graph comparing the size of the congestion window in TCP (solid line) to which the queue model according to the present invention is applied and conventional TCP Vegas. As shown in the graph, TCP using the queue model is steadily adapting even if external traffic continues to flow at short intervals. However, TCP Vegas has a timeout and eventually the CWND decreases to an initial value of 1. This is because TCP Vegas, which applies the method of increasing or decreasing the CWND size corresponding to one segment in every RTT, does not properly adapt to the change in the available bandwidth, which is greatly changed in an instant.
도 11a 및 도 11b는 각각 큐 모델을 적용한 TCP와 종래의 TCP Vegas에서 R1의 버퍼에 쌓인 데이터의 양을 나타낸 그래프로서 큐 모델을 적용한 TCP가 종래의 TCP Vegas를 적용한 경우에 비하여 우수한 성능을 나타냄을 알 수 있다.11A and 11B are graphs showing the amount of data accumulated in the buffer of R1 in TCP and the conventional TCP Vegas to which the queue model is applied, respectively, and show that the TCP to which the queue model is applied shows better performance than the conventional TCP Vegas. Able to know.
이로써 본 발명은 급격하게 가용대역폭이 변화하는 일반적인 상황에서 종래의 TCP Vegas 혼잡 제어 방법보다 효율적인 혼잡 제어가 가능함을 확인할 수 있다.Accordingly, the present invention can confirm that congestion control is more efficient than the conventional TCP Vegas congestion control method in a general situation in which the usable bandwidth is rapidly changed.
본 발명은, TCP 커넥션을 큐로 모델링하여 연결 상황에 맞게 CWND의 크기를 결정할 수 있어서, 종래의 TCP Vegas의 혼잡 제어 방법보다 우세한 성능을 얻을 수 있다. 또한 종래에 사용되던 방법의 일부만 수정하면 용이하게 적용이 가능하여 TCP를 적용하고 있는 소스나 리시버의 구현을 크게 바꿀 필요가 없어서 이를 적용하는데 큰 비용이 소요되지 않는 효과가 있다.The present invention can model the TCP connection as a queue and determine the size of the CWND according to the connection situation, thereby achieving superior performance over the conventional TCP Vegas congestion control method. In addition, it is possible to easily apply only a part of the conventionally used method, so there is no need to change the implementation of the source or receiver to which TCP is applied.
도 1은 종래의 TCP Vegas 모델에서의 혼잡 제어 설명도.1 is a diagram illustrating congestion control in a conventional TCP Vegas model.
도 2는 큐 모델에서 전송률에 대해 큐에 쌓인 패킷의 양을 나타내는 그래프.2 is a graph showing the amount of packets accumulated in a queue against the rate in the queue model.
도 3은 본 발명에 따른 큐 모델을 이용한 흐름 제어 및 혼잡 제어 방법을 나타내는 그래프.3 is a graph illustrating a flow control and congestion control method using a queue model according to the present invention.
도 4는 TCP 연결 링크에서 가용대역폭이 급격하게 한 번 바뀌는 경우 적용되는 네트워크 구조도.4 is a diagram illustrating a network structure applied when an available bandwidth suddenly changes once in a TCP connection link.
도 5는 도 4의 네트워크에서 TCP 연결과 외부 트래픽에 할당되는 가용대역폭 설명도.5 is an explanatory diagram of available bandwidth allocated to a TCP connection and external traffic in the network of FIG. 4; FIG.
도 6은 도 4의 네트워크에서 TCP Vegas 모델과 큐 모델을 적용한 TCP를 사용한 경우의 혼잡 윈도우의 크기를 비교한 그래프.FIG. 6 is a graph comparing the size of a congestion window when TCP is applied to a TCP Vegas model and a queue model in the network of FIG. 4. FIG.
도 7a 및 도 7b는 도 4의 네트워크에서 TCP Vegas 모델과 큐 모델을 적용한 TCP를 각각 사용하는 경우 R1 버퍼에 쌓인 데이터의 양을 비교한 그래프.7A and 7B are graphs comparing the amount of data accumulated in the R1 buffer when using the TCP Vegas model and the TCP to which the queue model is applied in the network of FIG. 4, respectively.
도 8은 TCP 연결 링크에서 가용대역폭이 수회 짧은 시간 간격으로 바뀌는 경우의 네트워크 설정도.Fig. 8 is a diagram illustrating a network setting when the available bandwidth is changed in several short time intervals in a TCP connection link.
도 9는 도 8에서 TCP 연결과 외부 트래픽에 할당되는 가용대역폭의 설명도.FIG. 9 is an explanatory diagram of available bandwidth allocated to a TCP connection and external traffic in FIG. 8; FIG.
도 10은 도 8에서 TCP Vegas 모델과 큐 모델을 적용한 TCP의 혼잡 윈도우 크기를 나타내는 그래프.FIG. 10 is a graph illustrating a congestion window size of TCP to which a TCP Vegas model and a queue model are applied in FIG. 8. FIG.
도 11은 도 8에서 TCP Vegas와 큐 모델을 적용한 TCP를 각각 사용하는 경우 R1 버퍼에 쌓인 데이터의 양을 비교한 그래프.FIG. 11 is a graph comparing the amount of data accumulated in an R1 buffer when using TCP Vegas and TCP applied with a queue model in FIG. 8. FIG.
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020040013054AKR101046473B1 (en) | 2004-02-26 | 2004-02-26 | Flow Control and Congestion Control Method of Transmission Control Protocol Using Network Model |
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020040013054AKR101046473B1 (en) | 2004-02-26 | 2004-02-26 | Flow Control and Congestion Control Method of Transmission Control Protocol Using Network Model |
| Publication Number | Publication Date |
|---|---|
| KR20050087316Atrue KR20050087316A (en) | 2005-08-31 |
| KR101046473B1 KR101046473B1 (en) | 2011-07-04 |
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020040013054AExpired - Fee RelatedKR101046473B1 (en) | 2004-02-26 | 2004-02-26 | Flow Control and Congestion Control Method of Transmission Control Protocol Using Network Model |
| Country | Link |
|---|---|
| KR (1) | KR101046473B1 (en) |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100717381B1 (en)* | 2005-09-09 | 2007-05-11 | 한국정보사회진흥원 | TCP Data Receiving Method based on Virtual Receive Buffer and Recording medium storing a program to implement the method |
| KR100772192B1 (en)* | 2005-12-01 | 2007-11-01 | 한국전자통신연구원 | Method and Device for controlling congestion in high bandwidth-delay product networks |
| CN101188473B (en)* | 2007-12-20 | 2010-06-09 | 上海交通大学 | Adaptive adjustment method of transmission layer transmission rate in wireless ad hoc networks |
| KR20150125471A (en)* | 2014-04-30 | 2015-11-09 | 삼성전자주식회사 | METHOD AND APPARATUS FOR CONTROLLING CONGESTION IN A WIRELESS NETWORK USING Transmission Control Protocol |
| CN116527587A (en)* | 2023-04-25 | 2023-08-01 | 南京大学 | System and method for realizing weight distribution of bandwidth based on AIMD |
| CN116527587B (en)* | 2023-04-25 | 2025-10-17 | 南京大学 | System and method for realizing weight distribution of bandwidth based on AIMD |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6490251B2 (en) | 1997-04-14 | 2002-12-03 | Nortel Networks Limited | Method and apparatus for communicating congestion information among different protocol layers between networks |
| KR100411447B1 (en)* | 2001-12-26 | 2003-12-18 | 엘지전자 주식회사 | Method of Controlling TCP Congestion |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100717381B1 (en)* | 2005-09-09 | 2007-05-11 | 한국정보사회진흥원 | TCP Data Receiving Method based on Virtual Receive Buffer and Recording medium storing a program to implement the method |
| KR100772192B1 (en)* | 2005-12-01 | 2007-11-01 | 한국전자통신연구원 | Method and Device for controlling congestion in high bandwidth-delay product networks |
| CN101188473B (en)* | 2007-12-20 | 2010-06-09 | 上海交通大学 | Adaptive adjustment method of transmission layer transmission rate in wireless ad hoc networks |
| KR20150125471A (en)* | 2014-04-30 | 2015-11-09 | 삼성전자주식회사 | METHOD AND APPARATUS FOR CONTROLLING CONGESTION IN A WIRELESS NETWORK USING Transmission Control Protocol |
| CN116527587A (en)* | 2023-04-25 | 2023-08-01 | 南京大学 | System and method for realizing weight distribution of bandwidth based on AIMD |
| CN116527587B (en)* | 2023-04-25 | 2025-10-17 | 南京大学 | System and method for realizing weight distribution of bandwidth based on AIMD |
| Publication number | Publication date |
|---|---|
| KR101046473B1 (en) | 2011-07-04 |
| Publication | Publication Date | Title |
|---|---|---|
| US6560243B1 (en) | System and method for receiver based allocation of network bandwidth | |
| US9455925B2 (en) | Method, device, and system for self-adaptively adjusting data transmission rate | |
| US7782777B2 (en) | Method and system for handling network congestion | |
| CN106301684B (en) | Media data transmission method and device | |
| Høiland-Jørgensen et al. | The Good, the Bad and the WiFi: Modern AQMs in a residential setting | |
| Ros et al. | Less-than-best-effort service: A survey of end-to-end approaches | |
| US8570864B2 (en) | Kernel awareness of physical environment | |
| CN104581422B (en) | A kind of method and apparatus transmitted for network data | |
| CN112653635B (en) | Congestion control algorithm improvement method, device, equipment and storage medium | |
| JP2008511205A (en) | Method and apparatus for controlling network congestion using queue control and one-way delay measurement | |
| CN104618258B (en) | A kind of control method of message transmission rate | |
| US9906427B2 (en) | Method for performing a bandwidth test for communications from a first network station to a second network station of a communication network and corresponding apparatuses for performing the method steps and corresponding computer program products | |
| US20070223492A1 (en) | Methods and apparatus for optimizing a TCP session for a wireless network | |
| US20090304014A1 (en) | Method and apparatus for local adaptive provisioning at a node | |
| US20240098155A1 (en) | Systems and methods for push-based data communications | |
| Naman et al. | Responsive high throughput congestion control for interactive applications over SDN-enabled networks | |
| US7149664B1 (en) | Method and apparatus for queue modeling | |
| Wang et al. | OSIA: Out-of-order Scheduling for In-order Arriving in concurrent multi-path transfer | |
| KR101837637B1 (en) | Streaming method based on Client-side ACK-regulation and apparatus thereof | |
| Yang et al. | Transient behaviors of TCP-friendly congestion control protocols | |
| KR20110086517A (en) | Adaptive buffer management method and device in communication system | |
| KR101046473B1 (en) | Flow Control and Congestion Control Method of Transmission Control Protocol Using Network Model | |
| Lu et al. | FAMD: A flow-aware marking and delay-based TCP algorithm for datacenter networks | |
| CN104580006B (en) | A kind of mobile network's method of controlling transmission rate, apparatus and system | |
| JP3853784B2 (en) | Data communication management method |
| Date | Code | Title | Description |
|---|---|---|---|
| PA0109 | Patent application | St.27 status event code:A-0-1-A10-A12-nap-PA0109 | |
| PG1501 | Laying open of application | St.27 status event code:A-1-1-Q10-Q12-nap-PG1501 | |
| R17-X000 | Change to representative recorded | St.27 status event code:A-3-3-R10-R17-oth-X000 | |
| A201 | Request for examination | ||
| PA0201 | Request for examination | St.27 status event code:A-1-2-D10-D11-exm-PA0201 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-3-3-R10-R18-oth-X000 | |
| D13-X000 | Search requested | St.27 status event code:A-1-2-D10-D13-srh-X000 | |
| D14-X000 | Search report completed | St.27 status event code:A-1-2-D10-D14-srh-X000 | |
| PN2301 | Change of applicant | St.27 status event code:A-3-3-R10-R11-asn-PN2301 St.27 status event code:A-3-3-R10-R13-asn-PN2301 | |
| E902 | Notification of reason for refusal | ||
| PE0902 | Notice of grounds for rejection | St.27 status event code:A-1-2-D10-D21-exm-PE0902 | |
| P11-X000 | Amendment of application requested | St.27 status event code:A-2-2-P10-P11-nap-X000 | |
| P13-X000 | Application amended | St.27 status event code:A-2-2-P10-P13-nap-X000 | |
| E701 | Decision to grant or registration of patent right | ||
| PE0701 | Decision of registration | St.27 status event code:A-1-2-D10-D22-exm-PE0701 | |
| GRNT | Written decision to grant | ||
| PR0701 | Registration of establishment | St.27 status event code:A-2-4-F10-F11-exm-PR0701 | |
| PR1002 | Payment of registration fee | Fee payment year number:1 St.27 status event code:A-2-2-U10-U11-oth-PR1002 | |
| PG1601 | Publication of registration | St.27 status event code:A-4-4-Q10-Q13-nap-PG1601 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| FPAY | Annual fee payment | Payment date:20140603 Year of fee payment:4 | |
| PR1001 | Payment of annual fee | Fee payment year number:4 St.27 status event code:A-4-4-U10-U11-oth-PR1001 | |
| PC1903 | Unpaid annual fee | Not in force date:20150629 Payment event data comment text:Termination Category : DEFAULT_OF_REGISTRATION_FEE St.27 status event code:A-4-4-U10-U13-oth-PC1903 | |
| PN2301 | Change of applicant | St.27 status event code:A-5-5-R10-R11-asn-PN2301 | |
| FPAY | Annual fee payment | Payment date:20160104 Year of fee payment:5 | |
| K11-X000 | Ip right revival requested | St.27 status event code:A-6-4-K10-K11-oth-X000 | |
| PC1903 | Unpaid annual fee | Ip right cessation event data comment text:Termination Category : DEFAULT_OF_REGISTRATION_FEE Not in force date:20150629 St.27 status event code:N-4-6-H10-H13-oth-PC1903 | |
| PR0401 | Registration of restoration | St.27 status event code:A-6-4-K10-K13-oth-PR0401 | |
| PR1001 | Payment of annual fee | Fee payment year number:5 St.27 status event code:A-4-4-U10-U11-oth-PR1001 | |
| R401 | Registration of restoration | ||
| PN2301 | Change of applicant | St.27 status event code:A-5-5-R10-R11-asn-PN2301 | |
| PN2301 | Change of applicant | St.27 status event code:A-5-5-R10-R14-asn-PN2301 | |
| P14-X000 | Amendment of ip right document requested | St.27 status event code:A-5-5-P10-P14-nap-X000 | |
| L13-X000 | Limitation or reissue of ip right requested | St.27 status event code:A-2-3-L10-L13-lim-X000 | |
| U15-X000 | Partial renewal or maintenance fee paid modifying the ip right scope | St.27 status event code:A-4-4-U10-U15-oth-X000 | |
| LAPS | Lapse due to unpaid annual fee | ||
| PC1903 | Unpaid annual fee | Not in force date:20160629 Payment event data comment text:Termination Category : DEFAULT_OF_REGISTRATION_FEE St.27 status event code:A-4-4-U10-U13-oth-PC1903 | |
| PC1903 | Unpaid annual fee | Ip right cessation event data comment text:Termination Category : DEFAULT_OF_REGISTRATION_FEE Not in force date:20160629 St.27 status event code:N-4-6-H10-H13-oth-PC1903 | |
| P22-X000 | Classification modified | St.27 status event code:A-4-4-P10-P22-nap-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 | |
| R18-X000 | Changes to party contact information recorded | St.27 status event code:A-5-5-R10-R18-oth-X000 |