컴퓨터 네트워크 3장- 혼잡제어

3.7 TCP 혼잡 제어

IP 계층은 네트워크 혼잡에 관해 종단 시스템에게 어떠한 직접적인 피드백도 제공하지 않으므로 전통적인 TCP는 네트워크 지원 혼잡제어 보다는 종단간의 혼잡 제어를 사용한다.

3.7.1 전통적인 TCP의 혼잡 제어

TCP가 취한 접근 방식은 네트워크 혼잡에 따라 연결에 트래픽을 보내는 전송률을 각 송신자가 제한하도록 하는 것.

1. TCP 송신자가 자신과 목적지 간의 경로에서 혼잡이 없음을 감지 ->송신율을 높인다.
2. TCP 송신자가 경로 사이에 혼잡을 감지 -> 송신율을 줄인다.

1. TCP 송신자는 자신의 연결에 송신자 전송 트래픽 전송률을 어떻게 제한하는가?

 송신 측에서 동작하는 TCP 혼잡 제어 메커니즘은 추가적인 변수인 혼잡 윈도(congestion window)를 추적한다.

• cwnd로 표시
• TCP 송신자가 네트워크로 트래픽을 전송할 수 있는 속도에 제약을 가한다.

 

송신하는 쪽에서 확인응답이 안 된 데이터의 양은 cwnd와 rwnd(수신 윈도 = 버퍼의 여유 공간)의 최솟값을 초과하지 않을 것이다. 늘렸다가 줄렸다가 가능함. 

LastByteSent - LastByteAcked ≤ min{cwnd, rwnd}

-> 따라서 cwnd의 값을 조절하여 송신자는 링크에 데이터를 전송하는 속도를 조절할 수 있다.

 

 

2. TCP 송신자는 자신과 목적지 사이 경로의 혼잡을 어떻게 감지하는가?

 

1. 손실 이벤트(loss event)가 발생한 경우 .... AIMD

과도한 혼잡이 발생하면

1. 경로에 있는 하나 이상의 라우터 버퍼들이 오버플로되고
2. 그 결과 데이터그램이 버려진다.
3. 버려진 데이터그램은 송신 측에서 손실 이벤트를 발생시킨다. ex) TimeOut 또는 3개의 Duplicated ACK의 수신

TimeOut -> 1MSS로 돌아간다 (TCP Reno, TCP Tahoe)

이를 통해 송신자는 송신자와 수신자 사이의 경로상의 혼잡이 발생했음을 알게 된다.

 

 

3. TCP 송신자는 송신율을 변화시키기 위해 어떤 알고리즘을 사용해야 하는가?

전송률을 제어하는 cwnd 값을 조정하는 매커니즘은 무엇인가?

• TCP 송신자들이 너무 빠르게 송신하면 -> 혼잡 붕괴가 나타날 것이다.
• TCP 송신자들이 너무 천천히 송신한다면 -> 네트워크 내의 대역폭을 충분히 활용하지 못할 것이다.

 

TCP는 다음과 같은 3가지 처리 원칙에 따라 자신이 송신할 속도를 결정하게 된다.

 

1. TCP 전송률은 한 세그먼트를 손실했을 때 줄여야 한다.

손실된 세그먼트 = 혼잡을 의미

손실 세그먼트의 재전송을 야기하는 이벤트는 다음과 같다.

• 타임아웃 이벤트
• 4개의 확인응답 수신 (하나의 원래의 ACK + 3개의 중복된 ACK)

 

2. 확인응답되지 않은 세그먼트에 대해 ACK가 도착하면 송신자의 전송률은 증가할 수 있다.

확인응답의 도착 = 네트워크가 송신자의 세그먼트를 수신자에게 성공적으로 전송하였다.

즉, 네트워크는 혼잡하지 않다는 묵시적 표시로 받아들여진다.

 

 

 

3.대역폭 탐색

혼잡이 없는 출발지에서 목적지까지의 경로를 표시하는 ACK와 혼잡한 경로를 표시하는 손실 이벤트가 주어지면,

1. TCP 송신자로 하여금 손실 이벤트가 발생할 때까지는 ACK가 도착함에 따라 전송률을 증가시킨다.
2. 손실 이벤트가 발생한 시점에서 전송률을 줄인다.

 

그러므로

1. TCP 송신자는 혼잡이 발생하는 시점까지 전송률을 증가시키고
2. 그 시점 이후로부터는 줄인 후,
3. 다시 혼잡 시작이 발생했는지를 보기 위한 탐색을 시작한다.

TCP 혼잡 제어 알고리즘(TCP congestion-control algorithm)

 

 

 

 

 

 

 

SlowStart

시작은 1MSS

ACK 마다 1MSS씩 증가하고 1 RTT마다 congetstion window가 double이 된다. 

한계값이 정해져 있고 시작은 느리나 점점 지수함수로 빠르게 증가한다.

슬로스타트의 종료 조건

이 지수적 증가는 언제 끝나는 것인가?

아래와 같이 3가지 경우가 존재한다.

 

 

1.타임아웃으로 표시되는 손실 이벤트(혼잡)가 있을 경우

1. TCP 송신자는 cwnd 값을 1로 설정
2. 새로운 슬로 스타트를 시작한다.

 

 

2.cwnd 값이 ssthreah 값과 같을 경우

1. 슬로 스타트는 종료되고
2. TCP는 혼잡 회피 모드로 전환한다.

• ssthreah(slow start threshold, 슬로 스타트 임곗값)는 두 번째 상태 변수로, cwnd/2로 정한다.
  (= 혼잡이 검출되었을 시점에서의 혼잡 윈도 값의 반)
• TCP는 혼잡 회피 모드에서는 cwnd를 좀 더 조심스럽게 증가시킨다.

 

 

3. 중복 ACK가 검출되는 경우

• TCP는 빠른 재전송을 수행하여 빠른 회복 상태로 들어간다.

 

빠른 회복 상태에서는 cwnd 값을 손실된 세그먼트에 대해 수신된 모든 중복된 ACK에 대해 1 MSS 만큼씩 증가시킨다.

congestion avoidance 상태로 변환 시키는 전환점은 ssthresh라는 점선이다. 

Tahoe : cwnd => 1 MSS

             ssthresh => 1/2

Leno : cwnd => 1/2 + 3

           ssthresh => cwnd

 

 

---

TCP 큐빅(CUBIC)

ACK 수신 시에만 혼잡 윈도를 늘리고 슬로 스타트 단계와 빠른 복구 단계는 TCP 리노와 동일하지만,
아래의 혼잡 회피 단계가 수정되었다.

 

 

 

 몇 가지 조율 가능한 큐빅 매개변수들이 프로토콜의 혼잡 윈도 크기가 얼마나 빨리 Wmax에 도달하는가(K)를 결정한다.

• Wmax : 손실이 마지막으로 감지되었을 때 TCP의 혼잡 제어 윈도 크기
• K 시각 : 손실이 없다고 가정할 때 TCP 큐빅의 윈도 크기가 다시 Wmax에 도달하는 미래 시점

 

 큐빅은 혼잡 윈도를 현재 시각 t와 K 시각 사이 거리의 세제곱 함수로 증가시킴

-> t가 K에 가까울 때보다 멀리 떨어졌을 때 혼잡 윈도 크기 증가가 훨씬 더 커진다.

 

즉,

1. 큐빅은 손실 전 속도인 Wmax에 가까워지도록 TCP의 전송 속도를 빠르게 증가시킨 다음,
2. Wmax에 가까워지면 대역폭을 조심스럽게 탐지한다. 천천히 증가 시킨다. 

 

 손실을 유발한 링크의 수준이 크게 변경된 경우 큐빅이 새 작동 지점을 더 빨리 찾을 수 있다.

• t가 K에 가까울 때는 큐빅의 혼잡 윈도 증가가 작다.
  (이는 손실을 유발하는 링크의 혼잡 수준이 많이 변경되지 않은 경우 좋음)
• t가 K를 크게 초과함에 따라 혼잡 윈도가 급격히 증가한다.

 

 

슬로 스타트 단계는 t0에서 끝나며,
t1, t2, t3 에서 혼잡 손실이 발생하면 큐빅은 Wmax에 가깝게 더 빠르게 증가 -> 따리서 TCP 큐빅이 더 많은 전체 처리량을 누린다.

 

Linux에선 디폴트로 설정. popular Web의 TCP들은 cubic을 사용한다. 

 

 

 

 

---

 

3.7.3 공평성

각각 다른 종단 간의 경로를 갖지만, 모두 R bps의 전송률인 병목 링크(bottleneck link)를 지나는 K개의 TCP 연결을 생각해보자.

 

 

souce -> dest -> source == > RTT Time

 

 

 

너무 큰 버퍼링 현상은 일어나지 않게 조정하기 위해 만듬

 RTTmin - minimum observed RTT (uncongested path) -> min 가진 값중 가장 작은 것. 가장 혼잡하지 않은 path를 가진 것. 

 uncongested throughput with congestion window cwnd is cwnd/RTTmin 

-> congestion이 안난 throughput을 계산 . 

 

delay 는 낮게, 넘치지 않게