KR101694271B1 - Multipath Cubic for Congestion control - Google Patents

Abstract

The present invention relates to a multi-path cubic algorithm for congestion control, which satisfies requirements for multi-path transmission, such as traffic shifting, throughput improvement, fairness, and the like, while maintaining an advantage of a TCP cubic algorithm advantageous in a high-speed long-distance network. A rate of increase of each sub-flow is reduced by a value corresponding to an inverse (r) of the amount of the increase when an MPTCP connection uses a TCP cubic algorithm as a congestion control method, thereby reducing a rate of overall increase related to an MPTCP.

Description

Multipath Cubic for Congestion Control for Congestion Control M-

The present invention relates to a multi-path CUBIC for congestion control, and more particularly, to a multi-path CUBIC for congestion control, and more particularly, to a multi- Path CUBIC for congestion control satisfying the requirement of path transmission.

A transmission control protocol (TCP) used in data communication is applied to a communication network to provide service reliability and network adaptability through data flow control and error control. In particular, TCP not only shows low delay and high throughput in a high-speed network, but also provides a seamless service by controlling data flow even in a congested network.

However, TCP has difficulty in streaming transmission in a network lacking reliability, such as a wireless environment, and congestion control is difficult when a single TCP path uses a congestion network.

In order to solve this problem, a multipath transmission control protocol (MPTCP) has been proposed.

There are various technologies related to MPTCP including Patent Documents 1 and 2.

Patent Document 1 relates to a method for supporting parallel transmission of data in multiple paths in multiple links in order to provide utilization efficiency in a large-scale BDP network in MPTCP,

In the case of (a) a mobile terminal performs a vertical handover, if the mobile network is a wireless data network, the mobile terminal disables the mobile communication network and sets the congestion window to a maximum value by setting the congestion window value (B) when the mobile terminal performs a vertical handover, if the mobile network is not a wireless data network, activating a mobile communication network and setting a congestion window (a congestion window value of the previous network × 1 / weight) To a congestion control method.

However, in order to design and operate a new protocol related to congestion control, various researches have to be carried out, and throughput must be improved at least through single-path TCP over the best path, TCP should be harmless (no harm), and the least congested path should be available.

In order to improve the throughput, it is necessary to use the available path efficiently compared to the single path TCP. To maintain the congestion balance without harming the existing TCP, fairness, responsiveness, and MPTCP traffic movement it should be possible to guarantee traffic shifting.

Therefore, the Multipath Congestion Control Algorithm (MCCA) satisfies the above requirements and must be able to best maintain and coordinate the transmission rate of the subflow in order to achieve the design objective.

Linked Increment Algorithms (LIAs) have been developed to meet these needs.

LIA is an extension of TCP New RENO for congestion control of MPTCP. LIA is the congestion window size increase factor (1) and

수식(1)

Equation (1)

By doing so, it compensates for the inconsistency of the RTT.

Where α is a parameter of the algorithm and represents the aggressiveness of the MPTCP.

The calculation of this parameter is given by the following equation (2).

수식(2)

Equation (2)

는 of 서브플로우

의 혼잡 윈도우 크기이고,

는 서브플로우

의 RTT이다. LIA의 설계는 통합 자원을 최적화하는 것과 민감도 사이에서 균형(tradeoff)를 이루는 것이다.In the above equation

Of the subflow

Is the congestion window size of <

Lt; RTI ID =

Of RTT. The design of the LIA is a tradeoff between optimizing integrated resources and sensitivity.

OLIA (Opportunistic Linked Increment Algorithm) algorithm has been proposed as a variant of this LIA, and it is expected to prevent "non-flappy" phenomenon of MPTCP using LIA.

를 증가시킨다.In OLIA, for each ACK of subflow r, according to the following equation (3)

.

수식(3)

Equation (3)

이다.here

to be.

는 혼잡 윈도우를 나타내고, B는 시간 t에서의 최상의 경로를 갖는 서브플로우의 집합이고, M은 시간 t에서 가장 큰 혼잡 윈도우 크기를 갖는 서브플로우의 집합을 나타낸다. 또한

은 MPTCP 접속의 전체 서브플로우 수를 나타내고,

는 집합 B에는 포함되나 집합 M에는 포함되지 않는 서브플로우의 수를 나타내며,

는 집합 M에는 포함되나 집합 B에는 포함되지 않는 서브플로우의 수를 나타낸다. 따라서 OLIA의 윈도우는 링크 상태가 가장 좋지만 윈도우 크기가 가장 작은 서브플로우의 윈도우 크기가 가장 빠르게 증가하며, 최대 윈도우를 갖는 서브플로우의 윈도우 크기는 늦게 증가한다.In the above formula

B is the set of subflows with the best path at time t and M is the set of subflows with the largest congestion window size at time t. Also

Represents the total number of sub-flows of the MPTCP connection,

Represents the number of sub-flows included in set B but not included in set M,

Represents the number of sub-flows included in the set M but not included in the set B. Therefore, the OLIA window has the best link state, but the window size of the subflow with the smallest window size increases the fastest, and the window size of the subflow with the largest window increases later.

에 의해서 스케일된 임계지점에서의 윈도우 크기의 증가와 감소는 수식(4)와 같다.wVegas (weighted Vegas) is an extended concept of TCP Vegas. wVegas is a delay-based MPTCP algorithm that uses the queuing delay of packets as a signal to congestion. In this algorithm, a weight factor is assigned to each subflow and adaptively adjusted according to congestion. For each RTT,

The increase and decrease of the window size at the critical point scaled by (4) are as shown in Equation (4).

수식(4)

Equation (4)

는 최소의 RTT이며, 서브플로우 r의 현재 RTT를 나타내고,

는 전체 처리율에 대한 기대 처리율의 비율이다.α and β are two threshold values and are defined by TCP Vegas.

Is the minimum RTT and represents the current RTT of subflow r,

Is the ratio of the expected throughput to the total throughput.

On the other hand, the main characteristic of TCP Cubic is the window increasing function. As the name of the protocol indicates, the window increment function is a function of cubic and is determined by the following function.

수식(5)

Equation (5)

는 윈도우가 감소하기 이전의 윈도우 크기를 나타낸다. 그리고

이고, β는 패킷 손실이 발생했을 때 윈도우를 감소시키기 위해 적용되는 승수 감소 인자(multiplication decrease factor)를 나타낸다. 즉, 윈도우 크기가

로 감소한다. 도 1은 3개의 서로 다른 K 변수에 대해서 수식(5)에서의 윈도우 증가의 형태를 보여주며,

의 크기를 갖는다. In Equation (5), C is a scale factor, t is the elapsed time since the last window reduction,

Represents the window size before the window is decremented. And

And? Represents a multiplication decrease factor applied to reduce the window when packet loss occurs. That is,

. Figure 1 shows the form of the window increase in equation (5) for three different K variables,

.

에 가까워질수록 증가율이 감소하며,

값에 이르면 증가는 거의 멈춘다. 그리고 그 다음에 더 이상의 대역폭이 있는지를 확인하면서 다시 윈도우가 천천히 증가하기 시작하여

에서 멀어지면 증가속도를 높인다. 이와 같이

근처에서 증가 속도를 줄이는 것은 프로토콜의 안정성을 향상시키고, 네트워크 자원의 활용성을 높이며,

에서 멀어질수록 윈도우 증가 속도가 높아지는 것은 프로토콜의 확장성을 보장한다. 종래의 TCP Cubic 소스 코드에서 K 변수는 혼잡 윈도의 크기가

값에 도달할 때까지의 시간으로 나타나 있다. 실제로 도 1 (a)에 나타난 것과 같이 K 값이 증가함에 따라

에 도달하는 시간이 증가하는 것을 알 수 있으며, 선의 경사가 감소하는 것을 알 수 있다. 이것은 K 값이 TCP Cubic의 윈도우 증가 정도를 결정한다는 것을 나타낸다.
In general, the window size increases very rapidly from the reduced window

The rate of increase is decreased,

When the value is reached, the increase almost stops. And then the window starts to slowly increase again, making sure that there is more bandwidth

The speed of increase is increased. like this

Reducing the rate of increase in the vicinity increases the stability of the protocol, increases the availability of network resources,

Increasing the window growth rate as the distance from the window increases is the protocol scalability. In the conventional TCP Cubic source code, the K variable is the size of the congested window

And the time until the value is reached. Actually, as K value increases as shown in Fig. 1 (a)

, And it can be seen that the slope of the line decreases. This indicates that the value of K determines the degree of window increase of TCP Cubic.

1. Korean Patent Publication No. 10-2012-0065867 2. Korean Patent No. 1478751

As described above, the existing congestion control algorithm is proposed by the following two general design constraints.

The first is to reduce the aggressiveness of each sub-flow when sharing a link with a single TCP. Each sub-flow has a slower window growth rate to satisfy fairness when sharing a link with a single TCP, so that the link occupied by each sub-flow is smaller than a single TCP flow occupies on the same link. However, the transmission rate of the mode sub-flow should be guaranteed to be at least as high as the maximum transmission rate of a single TCP in the best path. This constraint is the most important factor for MPTCP to improve the throughput and achieve the goal of not harming the existing TCP. For example, LIA and OLIA use the same α parameter for all subflows to control the aggressiveness of the whole flow. do. The value of alpha is always less than one to ensure that the multipath flow is not larger than the capacity that a single path TCP can occupy.

Second, the transmission rates of all sub-flows cooperate to allow traffic shifting as well as responsiveness. Since the state of the network is not always constant, it is very important to acquire or release bandwidth quickly when the state of the network changes. The responsiveness characteristic indicates how quickly the MPTCP algorithm responds to network conditions. Therefore, one of the key points of the algorithm is to combine the procedures of processing the rate in each sub-flow and cooperate with each other so that load balancing as well as traffic shifting is achieved. Therefore, the bandwidth loss caused by congestion can be compensated and can be recovered by increasing the transmission rate of other sub-flows. As a result, congestion occurring in one sub-flow can increase the transmission rate of another path. This algorithm is made possible by using a function of the quality index of all sub-flows. If one of these quality indices changes its state, it reacts to this change and immediately causes another subflow to change. For example, the α factor used in the LIA and OLIA is a function of the expected transmission rate of all sub-flows and is used to control not only aggression but also the traffic with the least congestion. On the other hand, the weights used in wVegas quantify the aggressiveness of bandwidth competition by comparing the expected rate with the total rate of all sub-flows. As a result, less congested sub-flow paths can compete for aggressive bandwidth gain by getting larger weights. Thus, wVegas is more sensitive to changes in the congestion situation of the network, can achieve the traffic movement properly, and converges faster.

That is, the present invention has been developed in order to overcome the problems of the related art as described above. In order to maintain the congestion balance without harming the existing TCP as well as having high throughput in the wide area network with high delay, fairness, responsiveness, and multipoint CUBIC for congestion control that can guarantee traffic shifting of MPTCP.

)의 역에 해당하는 만큼 감소시켜 전체 MPTCP의 증가율을 감소시킨 것을 특징으로 한다.In order to achieve the above object, the multipath CUBIC for congestion control according to the present invention increases the rate of increase of each sub-flow when the MPTCP connection uses TCP Cubic as a congestion control scheme

), Thereby decreasing the rate of increase of the entire MPTCP.

)가 TCP Cubic 윈도우 증가 함수에서 윈도우 최대 크기에 도달해서 링크의 제한된 용량까지 도달할 때까지의 시간인 변수(K)보다 큰 것이 바람직하다.Variables of function of quality index of subflow (

) Is greater than the variable K, which is the time from reaching the window maximum size to reaching the limited capacity of the link in the TCP Cubic window increasing function.

At this time, the transmission rate of the MPTCP connection is

to be.

일 때

이 되며 MPTCP의 전송율은 다음과 같이 된다.If the quality of the subflow is constant,

when

And the transmission rate of MPTCP is as follows.

This means that the transmission rate of the MPTCP connection expected by using M-CUBIC is always higher than the transmission rate of single-path TCP, and it also works well with TCP Cubic.

As described above, the multi-path CUBIC for congestion control according to the present invention allows each sub-flow of the MPTCP to lower the aggressiveness of the single-path TCP sharing the link, There is an effect that traffic shifting can be performed in order to maintain the load balance.

Therefore, the MCubic proposed in the scenario with the bottleneck link and the scenario with the bottleneck link with the separated bottleneck can improve the performance of MPTCP.

FIG. 1 is a graph showing a form of window increase of TCP Cubic and M-CUBIC for three different K variables.
FIG. 2 is a block diagram illustrating a configuration example of a communication system having a separated bottleneck scenario to which a multipath CUBIC for congestion control according to the present invention is applied
Figure 3 illustrates the throughput of a single path TCP flow and MPTCP connection for various congestion control schemes in a separate bottleneck scenario
FIG. 4 illustrates a single path TCP flow for various congestion control schemes in a separate bottleneck scenario and a fairness index of an MPTCP connection
5 is a block diagram showing a configuration example of a communication system having a shared bottleneck scenario to which a multipath CUBIC for congestion control according to the present invention is applied
Figure 6 shows a comparison table of single-path TCP and MPTCP when link delays are the same in the shared bottleneck scenario
Figure 7 shows a comparison table of single path TCP and MPTCP when link delays are different in the shared bottleneck scenario

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Like reference numerals are used for like elements in describing each drawing. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

The multi-path CUBIC for congestion control according to the present invention reduces the rate of increase of the entire MPTCP by decreasing the rate of increase of each sub-flow corresponding to the inverse of increment () when the MPTCP connection uses TCP Cubic as a congestion control scheme .

)가 TCP Cubic 윈도우 증가 함수에서 윈도우 최대 크기에 도달해서 링크의 제한된 용량까지 도달할 때까지의 시간인 변수(K)보다 큰 것이 바람직하다. In addition, the variable of the function of the quality index of the sub-

) Is greater than the variable K, which is the time from reaching the window maximum size to reaching the limited capacity of the link in the TCP Cubic window increasing function.

The transfer rate of an MPTCP connection is

으로 정의 될 수 있다.

. ≪ / RTI >

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

) 값에 도달할 때까지의 시간으로, TCP Cubic을 사용하는 각 플로우의 전송율을 결정한다. 따라서 K 값이 크면 증가율이 낮게 된다.As described above, the K variable indicates that the size of the congestion window is smaller than the window size before the window decreases

) Value is reached, the transmission rate of each flow using TCP Cubic is determined. Therefore, if the value of K is large, the rate of increase is low.

)라고 부르는 수정된 K 값을 사용한다. In the present invention, for the multipath transmission, the variable of the function of the quality index of the sub-

). ≪ / RTI >

는 원래의 K보다 커야 하며, C2에서 변수

는 서브플로우의 품질 지표의 함수이어야 한다. In C1, each sub-flow does not increase the congestion window faster than a single-path TCP flow

Must be greater than the original K, and the variable in C2

Should be a function of the quality index of the subflow.

는 플로우의 증가율을 나타낸다. Therefore, the value of MCubic must be determined and analyzed. In the TCP Cubic window increase function, the K variable represents the time until the window reaches the maximum size and reaches the limited capacity of the link. ratio

Represents the rate of increase of the flow.

를 갖는 혼잡 제어 알고리즘을 사용하며, 증가율은

이 된다. 따라서 MPTCP 접속의 증가율은

이 된다. 단일 경로와 비교했을 때 MPTCP 접속은 서브플로우의 증가율을 증가분(

) 시간보다 빠르고, 이는 MPTCP 접속이 TCP Cubic을 사용하는 단일 경로 TCP에 대해서 공정하지 못 하다는 것을 의미한다. 따라서 공정성을 확보하기 위해서 MCubic는 MPTCP 접속이 혼잡 제어 방식으로 TCP Cubic을 사용할 때, 각 서브플로우의 증가율을 증가분(

)의 역에 해당하는 만큼 감소시킨다. 그렇게 하면 전체 MPTCP의 증가율은 감소할 것이고, 감소시킨 후에

번째 서브플로우의 증가율은 수식(6)과 같이 일정하게 된다. Assuming that there are n flows belonging to MPTCP,

Lt; / RTI > using a congestion control algorithm with

. Therefore, the rate of increase of MPTCP connection is

. Compared to a single path, an MPTCP connection increases the growth rate of the subflow (

) Time, which means that MPTCP connections are not fair for single-path TCP using TCP Cubic. Therefore, in order to ensure fairness, MCubic increases the rate of increase of each sub-flow when MPTCP connection uses TCP Cubic as a congestion control method

), As shown in FIG. This will reduce the rate of growth of the entire MPTCP,

Th sub-flow is constant as shown in Equation (6).

수식(6)

Equation (6)

The expected rate of MPTCP connection is shown in Equation (7).

수식(7)

Equation (7)

일 때

이 되며, 수식(7)을 다시 정리하면 수식(8)과 같이 된다. If the quality of the subflow is constant,

when

(7) is rearranged as shown in Expression (8).

수식(8)

Equation (8)

This means that the expected rate of MPTCP connection using MCubic is always higher than that of single-path TCP, and it also works well with TCP Cubic. As a result, MCubic satisfies the goal of efficiently using the available paths when compared with single-path TCP and improving the existing TCP.

)를 갖는 단일 경로 TCP Cubic과 변수(

)를 갖는 두 개의 서브플로우로 이루어진 MCubic의 윈도우 증가함수를 보여주고 있다. MCubic을 사용함으로써 변수(

)를 갖는 서브플로우의 각 전송율은 변수(

)를 갖는 단일 경로 TCP의 전송율보다 항상 낮다는 것을 알 수 있다. 반면에 증가분(

)에 의해서 하나의 서브플로우는

비율만큼 감소하게 되며, 전체적으로

만큼 감소하게 된다. 따라서 다른 서브플로우의 전송율을 즉시 증가할 수 있게 하며, 혼잡이 발생했을 때 트래픽 이동이 가능해지는 것이다. 마지막으로 MCubic을 사용함으로써 n개의 서브플로우에 속하는 각

서브플로우는 아래의 수식(9)에 따라서 자신의 윈도우 크기를 주기적으로 조정한다.This result is shown in Fig. 1 (b)

) And a single-path TCP Cubic with variable

), Which is composed of two subflows. By using MCubic variable (

) ≪ / RTI > is < RTI ID = 0.0 >

Which is always lower than the transmission rate of a single-path TCP. On the other hand,

) ≪ / RTI >

Ratio, and as a whole

. Therefore, it is possible to immediately increase the transmission rate of other sub-flows, and traffic can be moved when congestion occurs. Finally, by using MCubic, the angles belonging to n subflows

The subflow periodically adjusts its window size according to the following equation (9).

수식(9)

Equation (9)

이다.here

to be.

는 항상 원래의 값

보다 크다. 하나의 서브플로우에서 혼잡이 발생했을 때 다른 서브플로우의

가 즉시 감소함으로써 다른 서브프로우의 전송율이 증가하고 혼잡되는 서브플로우의 전송율을 보상하게 된다.
Under normal conditions

Is always the original value

Lt; / RTI > When congestion occurs in one sub-flow,

The transmission rate of the other sub-flows is increased and the transmission rate of the congested sub-flows is compensated.

Example 1 (Implementation and performance evaluation)

The multi-path CUBIC for congestion control according to the present invention implements MCubic in the MPTCP supported by the Linux kernel 3.14.17. Basically, MCubic is similar to Cubic, and the algorithm of the present invention is applied to the K variable in the Cubic increasing function. Slow start and multiplicative decrease when packet loss occurs are the same as TCP Cubic. The following Algorithm 1 shows the pseudo code of the main function for the Cubic algorithm.

Example 2 (Test Bed and Performance Evaluation-Discrete Bottleneck Scenario)

The system shown in FIG. 2 is a system composed of split bottleneck scenarios and is intended to evaluate the performance of MCubic in comparison with other MCCAs, especially TCP Cubic, in terms of fairness and traffic shifting. The testbed of FIG. 2 has a symmetrical topology and has bottleneck links that are separate from each other in flows A1-B1 and A2-B2 flows, sharing a link with a single-path TCP Cubic. Two paths are asymmetrically constructed to observe the traffic shifting capability of the algorithm. The A1-B1 is 100 Mbps and the second link A2-B2 is 10, 20, 30 and 50 Mbps The change in capacity was given.

In order to control the capacity of the link easily, we used the dummynet bridge in each path to set the link capacity as desired. The flow of single path TCP and MPTCP started and ended identically, and the throughput (Mb / s) of each link was measured over time.

Figure 3 shows the overall throughput of two single-path TCP flows and multipath connections according to different congestion control schemes. In FIG. 3, the MCubic multi-path connection has the least bandwidth than the other schemes. In particular, it has the smallest bandwidth in the case of TCP Cubic. This is the result of applying the design constraint C1, and by lowering the transmission rate of each sub-flow of the MCubic sharing the link.

This is also to make each sub-flow sharing the link less aggressive. As a result, we show that MCubic is more friendly to two single-path TCP flows than other algorithms. Also, this result can be known from the fairness index calculated as in Equation (9), and FIG. 4 shows the calculation result.

In this scenario, fairness is required for TCP flows and MPTCP connections to share bottleneck links. To calculate the fairness of the user average throughput, Jain's Fairness Index is used as shown in Equation (10) below.

수식(10)

Equation (10)

은

접속의 처리율이고, 경쟁하는 n개의 개체가 있다. 실험 결과 MCubic의 트래픽 이동 효과로 인해서 모든 테스트의 경우에 MCubic의 공정성 지수가 가장 높았으며, 특히 원래의 TCP Cubic과 비교했을 때 가장 좋은 결과를 보여줬다.
In Equation (10)

silver

The throughput of the connection, there are n competing entities. Experimental results showed that MCubic 's fairness index was the highest in all tests due to MCubic' s traffic movement effect, and it showed the best result especially compared with the original TCP Cubic.

Example 3 (performance evaluation with a test bed - shared bottleneck scenario)

In the third embodiment, as shown in FIG. 5, the bottleneck link is configured to be shared between the MPTCP and the single-path TCP Cubic. All links in the test bed have a capacity of 100 Mbps. As with the separate bottleneck scenario, the single path TCP flow and the MPTCP flow are started and terminated at the same time.

There are two cases of shared bottleneck scenarios: one in which the connections in MPTCP have the same delay (case 1: when the delay of the link is the same) and another case (case 2: the delay of the link is different) Respectively.

Case 1 is intended to observe the efficiency of MPTCP in various tests under high network latency conditions. It is considered normal if the delay of the Internet is less than 100 ms, but the latency of the Internet via satellite is typically 500 ms or more It is known. Therefore, in this embodiment, a condition having a further delay is configured by using a dummy-net bridge.

The throughput (Mb / s) for the individual connections at the transmitting end was measured, and the results are shown in FIG.

In a good condition with a delay of 100ms or less, we can see that the result of MPTCP implemented in MCubic is higher than that of single-path TCP, similar to other protocols. However, even if the delay (500 ms) increases to the satellite Internet level, the advantage of TCP Cubic is maintained, and the throughput is higher than or equal to a single TCP. Compared with other approaches, it is less than a single TCP flow. This is the result of not achieving the design goal of making the available paths efficient when compared to single-path TCP, and is re-described by calculating the ratio of multipath to single path in Table 1 below. By using MCubic, the ratio is always greater than or equal to 1 while the other protocols are smaller than 1 for large latency networks. Therefore, it can be seen that MCubic has advantages in large networks.

Table 1

In case 2, as described above, the delay of the link in the shared bottleneck scenario is different, so that the first sub-flow of the MPTCP and the single-path TCP flow have the same good 100 ms delay. However, the link of the second sub-flow was experimented by using a dummynet bridge to change the delay to 300, 400 and 500 ms.

Figure 7 shows the test results when two sub-flows are asymmetric. In Figure 7, the performance of MPTCP is lower than that of single-path TCP. This is because it takes a long time to rearrange the order of the packets in the MPTCP receive buffer. Therefore, the performance decreases as the RTT (Round Trip Time) increases. This phenomenon also occurs in MPTCP using MCubic. Nevertheless, MCubic maintains a throughput ratio between MPTCP and single-path TCP, and the results are shown in Table 2 below.

Table 2

As described above, each sub-flow of the MPTCP can reduce the aggressiveness of the single-path TCP sharing the link, and can reduce the traffic mobility to maintain fairness and load balance between the sub- traffic shifting.

Claims (10)

A method for controlling congestion in a network using a Multipath Transmission Control Protocol (MPTCP), the method comprising:
The function variable (Kmptcp) of the quality index is introduced for n TCP subflows for data communication between a client and a server connected by MPTCP to calculate the window size increase rate of the i-th TCP subflow as shown in the following Equation (1) A process of determining;
Determining a data transmission rate between the MPTCP access client and the server using Equation (2) below; And
wherein the i-th TCP sub-flow comprises adjusting the window size using the window increasing function of Equation (3) below.

[Equation 1]

(Here, Ki is the time until the size of the congestion window of the ith TCP subflow in the TCP Cubic algorithm reaches the window size (Wmax) before the window is decremented, 1 / Ki is i Th < / RTI > TCP subflow)

&Quot; (2) "

&Quot; (3) "

(From here,

, C is the scale factor, t is the elapsed time since the congestion window was last reduced, Wmax is the window size before the congestion window decreased, and β is the multiplier applied to reduce the window when packet loss occurs factor)
delete delete delete delete delete The method according to claim 1,
When congestion occurs in one of the n TCP sub-flows,

And the window size is increased to compensate for the transmission rate of the congested TCP sub-flow.
delete delete The method according to claim 1,
A method for controlling congestion in a network using a multipath transmission control protocol, characterized in that a method for controlling the congestion can be implemented in an MPTCP network when a single path TCP Cubic network and an MPTCP network are configured to share a router .

Images