minzzl
[논문번역] Performance Analysis of TCP Congestion Control Algorithms 본문
안녕하세요 ,
Congestion control 기반 선행 연구를 분석하기 위해 논문 번역을 하고, 그 과정에서 정리를 해볼까합니다.
QUIC은 최근에 나온 프로토콜이라그런지, 마땅한 논문이 별로 없더라구요 ...~
그래서 TCP 기반으로 차차 읽어보겠습니당
우선 첫번째 논문입니다 ^^ !
https://www.naun.org/main/UPress/cc/cc-27.pdf
(2023.03.08일 기준)
발행년도 : 2008
인용수: 70
Abstract
대용량 데이터의 빠른 전송과 네트워크 인프라 구축에 대한 수요는 계속 증가하고 있습니다.
그러나 오늘날 지배적인 전송 프로토콜인 TCP는 신속성보다 안정성을 선호하고, 보수적인 혼잡 제어 알고리즘의 한계로 인해 네트워크 용량을 충분히 활용하지 못하기 때문에, 이러한 수요를 충족시키지 못합니다. 고속 장거리 네트워크에서 TCP의 느린 응답은 이러한 네트워크에서 상당한 규모의 미사용 대역폭을 남깁니다.
보다 적극적인 혼잡 제어 알고리즘을 채택하여 연결의 처리량을 개선하기 위해 다양한 TCP 변형이 제안되었습니다.
패킷 손실을 혼잡의 지표로 사용하는 손실 기반 고속 TCP 혼잡 제어 알고리즘,
패킷 전송 속도를 결정하는 신호로 패킷 손실보다는 패킷 지연을 강조하는 지연 기반 TCP 혼잡 제어 등이 있습니다.
손실 기반 알고리즘과 지연 기반 알고리즘의 특징을 결합하여 공정한 대역폭 할당과 흐름 간의 공평성을 달성하려는 노력도 있습니다.
여기에서는 표준 TCP 혼잡 제어(TCP Reno), 손실 기반 TCP 혼잡 제어(고속 TCP, 확장 가능한 TCP, 큐빅 TCP), 지연 기반 TCP 혼잡 제어(TCP Vegas), 혼합 손실-지연 기반 TCP 혼잡 제어(복합 TCP) 등 다양한 방식의 TCP 혼잡 제어를 연결 설정 후 경과 시간 대비 혼잡 창으로 비교 분석해 보았습니다.
-> 네트워크 인프라 구축에 대한 수요는 증가하고 있지만, TCP의 보수적인 혼잡 제어 알고리즘의 한계로 네트워크 용량을 충분히 활용하지 못해서 상당한 미사용 대역폭은 남김. 따라서 해당 논문에서는 다양한 방식의 혼잡 제어 방식을 비교분석함
I. INTRODUCTION
고속 데이터 네트워크를 통해 대량의 데이터를 빠르게 이동하는 것은 많은 애플리케이션에서 요구되는 사항입니다. 이러한 애플리케이션에는 네트워크 노드 간 고대역폭 링크가 필요합니다. 인터넷의 안정성을 유지하기 위해 모든 애플리케이션은 혼잡 제어를 받아야 합니다. TCP 는 잘 개발되고 광범위하게 사용되며 널리 사용되는 인터넷 전송 프로토콜입니다. TCP는 빠르고 효율적이며 네트워크 혼잡 상태에 반응하지만 TCP 혼잡 제어 사용에 대한 한 가지 반대 의견은 TCP의 AIMD 혼잡 백오프 알고리즘이 윈도우 크기를 너무 갑작스럽게 감소시켜 데이터 속도를 저하시킨다는 것입니다.
표준 TCP는 현실적인 환경에서 달성할 수 있는 혼잡 윈도우를 제한합니다. 지난 몇 년 동안 활용도 저조 문제를 해결하기 위한 TCP 변형이 급증했는데, 특히 TCP 혼잡 윈도우의 느린 성장으로 인해 TCP가 높은 BDP 네트워크에 불리하게 작용하는 것을 목격했습니다. 나머지 논문은 다음과 같이 구성되어 있습니다:
TCP 수정 및 새로운 프로토콜을 포함한 관련 작업은 섹션 2에서 검토합니다. 표준 TCP 혼잡 제어 알고리즘은 섹션 3에서 설명합니다. 패킷 손실을 혼잡의 암시적 표시로 사용하는 세 가지 대표적인 윈도우 기반 고속 TCP 혼잡 제어 알고리즘이 섹션 4에 설명되어 있습니다. 지연 기반 TCP 혼잡 제어인 TCP Vegas는 섹션 5에서 설명합니다. 복합 TCP 접근 방식은 섹션 6에서 설명합니다. 두 가지 네트워크 토폴로지의 다양한 시나리오에 대한 혼잡 윈도우 성장 함수와 경과 시간 측면에서 이러한 알고리즘을 비교 분석하는 내용은 섹션 7에 나와 있습니다. 마지막으로 섹션8에서 이 연구를 마무리합니다.
-> 인터넷 안정성을 유지하기 위한 TCP의 혼잡 제어 방식은 윈도우의 느린 성장을 발생 시킴. 따라서 높은 BDP 네트워크에 불리하게 작용
II. BACKGROUND AND RELATED WORK
우리가 TCP Reno[1]라고 부르는 표준 TCP 혼잡 제어 알고리즘은 1988년에 개발되었습니다. [4], [5], [6], [7], [8], [10], [15]는 TCP Reno의 몇 가지 개선 사항을 설명합니다.
혼잡 조건에서 혼잡 창을 업데이트하는 TCP의 보수적인 접근 방식을 다루는 몇 가지 수정 사항은 다음과 같습니다:
i. 손실 기반 TCP 혼잡 제어: HSTCP [11], BIC-TCP [12], STCP [13], CUBIC-TCP [16], HTCP [17] 등.
ii. 지연 기반 혼잡 제어: TCP-Vegas [22], Fast-TCP [3], TCP-LP [18] 등.
iii. 혼합 손실-지연 기반 TCP 혼잡 제어: 복합 TCP [19], TCP 아프리카 [20] 등.
iv. 명시적 혼잡 알림: XCP[21] 등
이러한 프로토콜의 대부분은 확장 가능한 방식으로 TCP의 윈도우 성장 함수를 수정하는 것을 다룹니다. Tomoya 등[2]은 고속 네트워크에서 효율적인 데이터 전송, TCP Reno와의 공평성, RTT가 다른 플로우 간의 공정한 대역폭 할당을 실현하는 TCP 친화적인 혼잡 제어를 제안했습니다. 슬로우 스타트/혼잡 회피 방식을 사용하는 대신 새로운 승인을 수신할 때마다 혼잡 윈도우의 크기를 결정하는 방식이 [14]에서 제안되었습니다.
-> TCP 혼잡 제어 방식을 개선하기 위한 다양한 방법들이 제안되었음
III. TCP Reno
TCP Reno는 수신된 각 ACK에 대해 왕복 시간(RTT)당 한 세그먼트씩 혼잡 윈도우 W를 증가시키고 왕복 시간당 각 손실 이벤트에 대해 혼잡 윈도우를 절반으로 감소시키는 TCP의 AIMD 메커니즘을 구현합니다. TCP Reno는 다음과 같이 혼잡 윈도우를 제어합니다:
링크 대역폭이 변하지 않으면 TCP Reno는 주기적으로 윈도우 증가와 감소를 반복합니다.
패킷 손실률(p) 측면에서 TCP Reno의 혼잡 윈도우는 다음과 같이 정의됩니다.
방정식 (3)에서 볼 수 있듯이 TCP Reno는 현실적인 환경에서 TCP가 달성할 수 있는 혼잡 윈도우에 심각한 제약을 가합니다.
예를 들어 1500바이트 패킷과 100ms RTT를 사용하는 TCP Reno 연결의 경우 정상 상태 처리량 1Gbps를 달성하려면 평균 혼잡 창이 8300개, 평균 패킷 손실률이 2 × 10-8(0.00000002)이어야 합니다. 이 요구 사항은 현재 네트워크에서 비현실적입니다. 혼잡 윈도우는 손실 이벤트 후 복구하는 데 4000 RTT 이상이 걸리므로 링크 대역폭을 효율적으로 사용할 수 없습니다. TCP는 큰 윈도우를 유지하기 위해 매우 작은 패킷 손실률이 필요하지만 실제 네트워크에서는 불가능합니다.
-> TCP 혼잡 제어 방식 중, 손실 기반 기법인 Reno 은 실제 환경에서 큰 혼잡 윈도우 크기를 달성하기 어려움
IV. HIGH-SPEED TCP VARIANTS
TCP는 저속~중속 네트워크(Kbps~수Mbps)에서는 매우 우수한 성능을 발휘하지만, 고속 네트워크 대역폭을 활용하는 데 매우 비효율적이기 때문에 고속(수십Mbps~Gbps)~초고속(Gbps~Tbps) 네트워크에서는 성능이 매우 떨어집니다.
- HighSpeed TCP (고속 TCP)
고속 TCP(HSTCP)[11]는 큰 혼잡 구간이 있는 TCP 연결에 사용하기 위해 TCP의 혼잡 제어 메커니즘을 수정한 것입니다. 고속 TCP의 수정된 응답 기능은 혼잡 윈도우가 클 때만 적용되며, 혼잡이 심한 환경에서는 TCP 동작을 수정하지 않으므로 혼잡 붕괴의 새로운 위험을 초래하지 않습니다. HSTCP는 WL, WH, PH의 세 가지 파라미터를 사용합니다. TCP 호환성을 보장하기 위해 HSTCP는 현재 혼잡 윈도우가 최대 WL인 경우 TCP Reno와 동일한 응답 함수를 사용하고, 현재 혼잡 윈도우가 WL보다 큰 경우 HSTCP 응답 함수를 사용합니다. HSTCP는 혼잡도가 낮거나 중간 정도일 때 표준 TCP의 응답 함수와 마찬가지로 로그 로그 스케일에서 직선을 따르도록 합니다. 평균 혼잡 윈도우의 값이 WL보다 큰 경우 응답 함수는 다음과 같습니다:
(WL보다 큰 경우 응답 함수)
패킷 손실률이 각각 PH와 PL인 경우 HSTCP는 평균 혼잡 윈도우 WH와 WL을 유지합니다.
권장 매개변수는 다음과 같습니다:
WL = 38, WH = 83000, PH = 10^-7입니다.
이 손실률은 고속 환경에서 달성 가능한 목표를 설정하는 동시에 패킷 손실률이 10^-4 또는 10^-5인 환경에서 표준 TCP와 경쟁할 때 고속 응답 기능에 대해 허용 가능한 공정성을 허용합니다. PL = 10^-3은 WL = 38일 때 방정식 (3)을 사용하여 계산됩니다. 따라서 HSTCP 응답 함수는 다음과 같이 계산됩니다:
방정식 (6)을 통해 HSTCP가 TCP Reno보다 더 공격적이며 패킷 드롭률이 10^-6인 환경에서 고속 TCP 연결은 표준 TCP의 10배 대역폭을 수신하게 되므로 불공평하다는 것을 알 수 있습니다.
->Reno와 비교했을 때, HSTCP 방식은 혼잡 윈도우를 더 효과적으로 활용할 수 있지만, 공격적이기 때문에 대역폭 사용에서 공정성이 떨어진다.
-
Scalable TCP
확장 가능한 TCP[13]는 점진적으로 배포할 수 있도록 설계되었으며, 작은 윈도우가 충분할 경우 기존 TCP 스택과 동일하게 작동합니다. 확장 가능한 TCP(STCP)와 고속 TCP는 원래 고속 백본 링크를 위해 설계되었으며, 차세대 인터넷에서 표준 TCP가 구현하는 현재의 혼잡 제어 메커니즘을 대체할 주요 후보로 보입니다. STCP는 TCP 혼잡 제어를 발신자 측에서 간단히 수정한 것으로, 다중 증가 다중 감소(MIMD) 기법을 사용합니다. 확장 가능한 TCP를 사용하면 높은 대역폭-지연 곱으로 네트워크 링크의 활용도를 높일 수 있습니다. STCP를 일반 TCP와 혼합하면 대역폭 지연 곱이 충분히 큰 영역의 대역폭을 STCP가 지배하게 됩니다. 이는 표준 TCP에 대한 비우호성을 보여줍니다.
확장 가능한 TCP는 알고리즘을 변경하여 TCP의 혼잡 윈도우를 다음과 같이 업데이트합니다:
STCP 응답 함수는 다음과 같이 계산됩니다:
패킷 손실 후 복구 시간은 13.42RTT, 즉 RTT에 비례하며 혼잡 윈도우 크기와 무관합니다. STCP 연결은 큰 혼잡 구간도 단시간에 복구할 수 있으므로 고속 네트워크에서 대역폭을 효율적으로 사용할 수 있습니다. TCP 연결의 MTU가 1500바이트이고 왕복 시간이 200ms라고 가정하면, 10Gbps 네트워크의 경우 STCP의 패킷 손실 후 혼잡 윈도우 복구 시간은 2.7초인 반면 표준 TCP의 경우 약 4시간 43분입니다.
-> SCTP는 MIMD 기법을 사용하여 효과적인 링크 활용도를 가지지만, Fairness가 떨어짐.
- CUBIC TCP
CUBIC TCP[16]는 이진 증가 혼잡 제어의 향상된 버전으로, 간단히 BIC[12]입니다. BIC의 성장 함수가 특히 짧은 RTT 또는 저속 네트워크에서 TCP에 비해 너무 공격적이기 때문에 BIC 윈도우 제어 기능을 단순화하고 TCP 친화성과 RTT 공정성을 향상시킵니다. 프로토콜 이름에서 알 수 있듯이 CUBIC의 윈도우 성장 함수는 마지막 손실 이벤트 이후 경과 시간에 따른 큐빅 함수이며, 그 모양은 BIC의 성장 함수와 매우 유사합니다. 큐빅 함수는 우수한 확장성과 안정성을 제공합니다. 이 프로토콜은 윈도우 성장률을 RTT와 무관하게 유지하므로, 프로토콜은 짧거나 긴 RTT에서 TCP 친화적으로 유지됩니다. CUBIC의 혼잡 에포크 기간은 패킷 손실률에 의해서만 결정됩니다. TCP의 처리량은 RTT뿐만 아니라 패킷 손실률에 의해서도 정의되기 때문에, CUBIC의 처리량은 패킷 손실률에 의해서만 정의됩니다. 따라서 손실률이 높거나 RTT가 짧은 경우 CUBIC은 TCP 모드로 동작할 수 있습니다. CUBIC의 혼잡 구간은 다음 함수에 의해 결정됩니다:
여기서 C는 스케일링 계수, t는 마지막 윈도우 감소 후 경과 시간, Wmax는 마지막 윈도우 감소 직전의 윈도우 크기,
K =(Wmaxβ/C) 1/3, 여기서 β는 손실 이벤트 발생 시 윈도우 감소에 적용되는 일정한 곱셈 감소 계수입니다(즉, 마지막 감소 시 윈도우가 βWmax로 감소됨). 합리적인 TCP 친화성, 공정성, 확장성 및 수렴 속도를 달성하기 위해 C는 0.4, β는 0.2, Smax(윈도우 증분)는 160으로 설정했습니다. CUBIC의 전체 창 증가 함수는 단 하나의 함수로 설명되며, BIC에서처럼 여러 단계의 창 제어가 필요하지 않으므로 BIC의 복잡성을 단순화할 수 있습니다. (BIC의 경우 이진 검색을 통해 창을 제어함!)
-> BIC을 개선한 CUBIC
V. DELAY-BASED CONGESTION CONTROL
TCP Vegas와 같은 지연 기반 TCP 혼잡 제어 알고리즘은 패킷 왕복 시간(RTT) 샘플에 포함된 혼잡 정보를 활용하려고 시도합니다.
- TCP Vegas
TCP Vegas는 패킷 전송 속도를 결정하기 위한 신호로 패킷 손실이 아닌 패킷 지연을 강조하는 TCP 혼잡 제어 알고리즘입니다. TCP Vegas는 패킷 드롭을 통해 실제로 정체가 발생한 후에야 정체를 감지하는 TCP Reno와 달리 연결에 있는 패킷의 RTT(Round Trip Time) 값의 증가를 기반으로 정체를 감지합니다. 이 알고리즘은 기본 RTT 값의 정확한 계산에 크게 의존합니다. BaseRTT는 측정된 모든 RTT의 최소값으로 설정되며, 일반적으로 연결에서 전송된 첫 번째 세그먼트의 RTT가 됩니다.
연결이 트래픽으로 인해 오버플로우되지 않는 경우 예상 처리량은 다음과 같습니다:
여기서 WindowSize는 현재 혼잡 윈도우의 크기입니다.
그런 다음 현재 실제 전송 속도는 왕복 시간당 다음과 같이 한 번 계산됩니다:
혼잡 창은 예상 전송률과 실제 전송률의 차이에 따라 조정됩니다.
또한 두 개의 임계값 a와 b가 정의되어 있어, a < b 및 a > b는 각각 네트워크에 추가 트래픽이 너무 적거나 너무 많은 경우에 해당합니다. 차이가 < a일 경우, TCP Vegas는 다음 RTT 동안 혼잡 윈도우를 선형적으로 증가시키고, 차이가 > b일 경우, TCP Vegas는 다음 RTT 동안 혼잡 윈도우를 선형적으로 감소시킵니다. a < Difference < b일 때는 혼잡 윈도우가 변경되지 않습니다.
-> 지연 기반의 방식을 활용하는 Vegas
VI. MIXED LOSS-DELAY BASED TCP CONGESTION CONTROL (혼합 손실-지연 기반 TCP 혼잡 제어)
손실 기반 고속 알고리즘은 대역폭 요구 사항을 충족하기 위해 공격적이지만 이러한 공격성은 TCP 불공정성 및 RTT 불공정성을 유발합니다. 지연 기반 접근 방식은 RTT 공정성을 제공하지만 TCP 공정성을 충족하기는 어렵습니다. 따라서 지연 기반 접근 방식과 손실 기반 접근 방식의 시너지 효과를 통해 두 접근 방식의 문제점을 해결하는 또 다른 접근 방식이 있습니다.
* RTT 공정성
RTT 공정성은 서로 다른 흐름의 RTT를 기반으로 네트워크 리소스를 공정하게 할당하는 것을 말합니다. TCP 혼잡 제어에서 발신자는 수신자와 네트워크에서 받은 피드백에 따라 전송 속도를 조정합니다. 동일한 네트워크 리소스를 놓고 경쟁하는 여러 TCP 흐름이 있는 경우, RTT 공정성을 통해 각 흐름이 RTT에 따라 사용 가능한 리소스를 동등하게 분배받도록 합니다. 즉, RTT가 짧은 플로우는 RTT가 긴 플로우에 비해 더 많은 대역폭을 확보할 수 있습니다.
* TCP 공정성
반면에 TCP 공정성은 네트워크 리소스를 공정하게 할당하는 것을 의미합니다. TCP 혼잡 제어에서 각 플로우는 네트워크에서 받은 피드백에 따라 전송 속도를 조정하여 처리량을 최대화하려고 합니다. TCP 공정성은 각 흐름이 사용 가능한 리소스를 동등하게 분배받도록 보장합니다. 즉, 동일한 네트워크 리소스를 놓고 경쟁하는 두 개의 흐름이 있는 경우 각 흐름은 사용 가능한 대역폭의 50%를 할당받게 됩니다.
요약하면, RTT 공정성과 TCP 공정성은 TCP 혼잡 제어에서 서로 다른 두 가지 개념입니다. RTT 공정성은 RTT를 기준으로 리소스를 공정하게 할당하는 반면, TCP 공정성은 플로우 수를 기준으로 리소스를 공정하게 할당합니다.
- Compound TCP (복합 TCP)
복합 TCP[23]는 확장 가능한 지연 기반 구성 요소를 표준 TCP 혼잡 회피 알고리즘에 통합합니다. 이 확장 가능한 지연 기반 구성 요소는 네트워크 사용률이 낮을 때 빠른 윈도우 증가 기능을 가지고 있으며, 혼잡 이벤트가 감지되면 전송 속도를 감소시킵니다. 컴파운드 TCP를 구현하기 위해 다음과 같은 상태 변수를 유지합니다. cwnd(혼잡 윈도우), dwnd(지연 윈도우), awnd(수신자 광고 윈도우).TCP 전송 윈도우는 다음과 같이 계산됩니다:
cwnd는 표준 TCP에서 제어되는 것과 동일한 방식으로 업데이트됩니다. 이 경우 ACK가 도착하면 cwnd는 다음과 같이 수정됩니다:
지연 기반 구성 요소는 위의 하위 섹션에서 설명한 대로 TCP Vegas에서 파생됩니다.
-> 지연 윈도우를 추가한 Compound TCP
VII. PERFORMANCE EVALUATION (성능 평가)
혼잡 시간 대비 경과 시간으로 성능을 평가했습니다.
네트워크 시뮬레이터 버전 2(ns-2)를 사용하여 손실 기반 고속 TCP의 세 가지 변형인 하이스피드 TCP, 스케일러블 TCP, 큐빅 TCP, 지연 기반 TCP 혼잡 제어인 TCP Vegas, 혼합 손실-지연 기반 TCP 혼잡 제어인 복합 TCP를 모든 실험에 기본 파라미터를 사용하여 TCP Reno와 비교 시뮬레이션했습니다. 다양한 고속 TCP 구현 간의 주요 차이점은 혼잡 이벤트에 대한 혼잡 윈도우 증가 동작에 있습니다. 실험은 두 가지 다른 토폴로지에서 수행됩니다. BDP는 30,000으로 설정했습니다. 모든 시뮬레이션은 시스템이 일관된 동작을 보일 수 있도록 충분히 오래 실행되었습니다. 그림 1과 그림 7은 각각 시뮬레이션 토폴로지 1과 2를 보여줍니다. 데이터 트래픽 유형은 두 시나리오 모두 FTP입니다.
- Simulation Topology 1
시뮬레이션 토폴로지 1의 경우, 0, 1, 2, 3으로 표시된 각 메인 노드에 동일한 수의 데이터 전송 노드가 연결됩니다. 이 토폴로지에서는 모든 메인 노드가 서로 직접 연결됩니다. 각 메인 노드(0, 1, 2, 3, 4, 5)에 연결된 노드 개수(여기서 i = 1, 2, 3, 4, 5) 간의 데이터 흐름은 다음과 같습니다:
위에 언급된 모든 알고리즘의 성능은 그림 1의 사례 a에 설명된 TCP 연결에 대해 개별적으로 테스트되었습니다.
- Reno
- HighSpeed TCP
- Scalable TCP
- CUBIC TCP
- TCP Vegas
- Compound TCP
그림 2-7은 시뮬레이션 토폴로지 1의 '케이스 A'의 결과를 보여줍니다. 각 소스 노드에 동일한 수의 싱크 노드가 연결되어 있기 때문에 모든 형태의 TCP 혼잡 제어가 동일한 응답을 제공하는 것을 알 수 있습니다. 따라서 각 메인 노드와의 링크의 총 사이드 대역폭이 메인 링크의 대역폭을 초과하더라도 패킷 드롭을 초래하는 심각한 혼잡 이벤트는 어떤 백본 링크에서도 발생하지 않습니다.
case b
사례 b는 시뮬레이션 토폴로지 1을 네 가지 방법으로 분석합니다. 시뮬레이션 결과와 함께 네 가지 시나리오가 아래에 나와 있습니다.
- TCP Reno, HighSpeed TCP, Scalable TCP and CUBIC TCP
그림 8은 각 네트워크 노드가 서로 다른 손실 기반 알고리즘을 사용하는 소스 노드로부터 데이터 트래픽을 수신할 때 심각한 혼잡 붕괴가 발생하지 않음을 보여줍니다. 그러나 TCP Reno는 다른 세 가지 알고리즘의 공격적인 윈도우 증가 동작으로 인해 패킷 드롭 이벤트로 인해 어려움을 겪습니다.
- TCP Reno, HighSpeed TCP, TCP Vegas and Compound TCP
이 네트워크 흐름에 대한 시뮬레이션 결과는 그림 9에 표시된 TCP Reno에 대한 불공정한 대역폭 할당도 보여줍니다. 고속 TCP 연결은 연결 시작 시 TCP 모드에서 작동하며, TCP Vegas는 연결 시작 시 BaseRTT를 계산하여 예상 처리량을 계산하고 실제 처리량과 예상 처리량의 차이에 따라 혼잡 윈도우를 늘리거나 줄이므로 연결 시작 시 TCP Vegas도 공격적인 시작을 하지 않습니다. 복합 TCP도 방정식 14와 15에 설명된 대로 대기하고 윈도우를 증가시킵니다. 혼잡 이벤트가 발생하지 않고 네트워크 사용률이 낮은 경우(예: 고속 TCP의 경우 cwnd = WL; TCP Vegas의 경우 차이 < a; 위의 섹션 V에서 설명한 복합 TCP) 모든 알고리즘은 혼잡 윈도우를 증가시키고 백본 링크의 연결이 증가함에 따라 패킷 드롭 이벤트가 발생하여 알고리즘이 혼잡 윈도우를 감소시키도록 재전송을 강제합니다.
- TCP Reno, TCP Vegas, Compound TCP and CUBIC TCP
그림 10에 표시된 이 시나리오에서는 심각한 혼잡 이벤트와 재전송이 발생하고 cwnd 증가 속도가 느려집니다. 손실 기반, 지연 기반, 혼합 손실-지연 기반 알고리즘을 기반으로 하는 네 가지 TCP 변형이 대역폭의 공정한 할당을 위해 경쟁하기 때문에 앞의 두 시나리오에 비해 cwnd 증가가 매우 느립니다.
- TCP Vegas, HighSpeed TCP, Scalable TCP and CUBIC TCP
그림 11은 고속 손실 기반 및 지연 기반 TCP 알고리즘이 대역폭 할당을 위해 서로 경쟁하기 때문에 시나리오 III과 마찬가지로 시나리오 IV에서도 심각한 혼잡이 발생하는 것을 보여줍니다.
'사례 b'의 네 가지 시나리오는 시나리오 I이 다른 모든 시나리오 중에서 최적의 결과를 보여줍니다. 따라서 손실 기반 또는 지연 기반 중 유사한 클래스에 속하는 TCP 알고리즘이 서로 경쟁하는 것이 가장 유리합니다. 손실 기반 알고리즘과 지연 기반 알고리즘이 서로 경쟁할 경우 심각한 문제와 느린 응답이 발생합니다.
- Simulation Topology 2
- TCP Reno
- HighSpeed TCP
- Scalable TCP
- CUBIC TCP
- CUBIC
- TCP Vegas
모든 TCP 구현에서 노드 0과 노드 1은 패킷 드롭 이벤트를 전혀 경험하지 않습니다. 그림 13과 그림 14는 각각 고속 TCP가 사용 가능한 네트워크 용량에 따라 두 가지 단계로 작동하기 때문에 TCP Reno와 고속 TCP에 대해 유사한 곡선을 보여줍니다. 두 TCP 알고리즘 모두 대부분의 TCP 연결의 혼잡 윈도우가 네트워크 용량에 도달할 때까지 증가하지 못합니다. 그림 15에 표시된 확장 가능한 TCP는 가장 공격적인 고속 TCP 변형으로 처리량 비율이 60.9이며 TCP Reno를 사용하면 최대 패킷 드롭 이벤트가 발생하고 시뮬레이션 토폴로지에서 최대 TCP 연결 수의 혼잡 윈도우가 100 패킷 이상으로 증가하지 못합니다. 그림 16은 CUBIC TCP의 혼잡 윈도우 증가 동작이 다른 손실 기반 TCP 변형에 비해 훨씬 더 부드럽고 매끄러우며, 혼잡 윈도우가 급격히 떨어지는 경우가 적고 넓은 범위의 경과 시간에 걸쳐 혼잡 윈도우가 일정하게 유지된다는 것을 보여줍니다. 복합 TCP의 동작은 그림 17에서 볼 수 있듯이 HSTCP와 거의 유사합니다. 마지막으로 그림 18은 TCP Vegas가 모든 TCP 혼잡 제어 알고리즘 중 가장 원활하며 대부분의 TCP 연결이 사용 가능한 용량에 도달할 때까지 증가한다는 것을 보여줍니다. 따라서 TCP Vegas는 각 연결에 공정한 대역폭을 할당하고 패킷 드롭 이벤트가 발생하지 않습니다. 따라서 이러한 네트워크 환경에서는 TCP Vegas를 지원하여 트래픽 흐름을 전송하는 것이 유리합니다.
