[네트워크] 13. TCP congestion control

TCP의 마지막입니다. congestion control에 대해 알아봅시다.(매우 중요)

 

1. Principles of congestion control

 

congestion control이란, 쉽게 말해서 너무 많은 데이터를, 너무 빠르게 보내서 network가 감당하지 못하는 상황을 조절하는 것입니다.

(flow control이랑은 다른 개념입니다)

 

congestion이 발생하면, packet loss나 long delay가 발생할 수 있습니다.

그럼 언제 congestion이 발생하는지, 예시를 들어보겠습니다. 

 

 

 

Host A는 라우터를 통해 데이터를 보낸다고 가정해봅시다.

라우터의 output link capacity가 R일 때, 두 개의 Host가 있으므로, 각각 connection에 대한 throughput은 R / 2가 됩니다.

 

이상적인 상황이기 때문에, 최대로 throughput은 R/2만큼 사용할 수 있고, 그에 가까워 질수록 delay는 무한대만큼 커집니다. (throughput과 delay의 관계는 예전에 배웠습니다.)

 

---

 

만약 라우터의 버퍼가 가득 찼을 경우는 어떻게 될까요?

 

라우터가 가득 차서 데이터를 못 받을수도 있으므로, 호스트는 기존 데이터를 복사해서 새롭게 보낼 때 기존의 데이터와 신규 데이터를 같이 보내게 됩니다.

 

이러한 경우, 시간은 조금 걸리지만 성공적으로 R/2의 output이 나올 수 있습니다.

 

---

 

하지만 실제 상황일 경우, duplicate 돼서 데이터가 전달될 수 있습니다.

예를 들어, 데이터를 다른 host에게 보냈는데, 성공적으로 전달됐는데도 불구하고 timeout이 걸려서 duplicated data를 보내게 된다면, output으로 중복된 데이터가 생길 것입니다.

 

 

output에 duplicated된 데이터가 하나라도 있다면, R/2에 절대 도달할 수 없게 됩니다.

 

---

 

 

또 다른 상황으로, 하나의 라우터에 여러 개의 host가 연결된 상황입니다.

많은 네트워크 구조가 이렇게 되어 있습니다. 이런 구조에서 host A의 input이 증가하게 된다면, 라우터의 버퍼가 많이 차게 됩니다.

라우터는 다른 host들도 공유해서 사용하므로, 다른 host 들의 통신 상태에도 영향을 끼치게 됩니다.

 

결과적으로는 네트워크 전체의 throughput에 악영향을 끼치게 됩니다.

 

packet loss가 생기게 되면, 패킷을 잃어버려서 1차적으로 손해가 발생하고, 다른 네트워크에도 피해를 줘서 2차 손해가 발생합니다.

이러한 것을 막기 위해, congestion control이라는 개념이 존재합니다.

 

 

 

 

congestion control은 크게 2가지 방식이 있습니다.

1. end - end congestion control : network로부터 feedback은 없지만, loss나 delay를 통해 congestion이 발생했는지 관찰.
2. network - assisted congestion control : router로부터 feedback을 받음

 

라우터는 할 일이 많기 때문에, end-end congestion control을 많이 사용합니다.

 

 

 

 

2. TCP congestion control

 

TCP 에서의 congestion control은 다음과 같은 특징이 있습니다.

1. additive increase : cwnd를 RTT 당 1MSS씩 증가시킵니다.
2. multiplicative decrease : loss가 생기면 cwnd를 1/2로 줄입니다.

 

 

 

2.1 TCP Slow Start

TCP slow start는, 처음 cwnd = 1 MSS로 잡고 시작한 후, 매 RTT마다 2배로 늘어난다는 것입니다.

이건 ACK를 하나 받을 때 마다 cwnd를 1씩 증가시켜서 이렇게 될 수 있습니다.

 

 

loss가 발생했을 때는, TCP의 종류마다 대처가 다릅니다.

Tahoe 방식과, RENO 방식으로 나뉘는데, 우선 간단하게 설명해보자면

Tahoe 방식은 timeout이나 3duplicate acks에 대해 모두 cwnd 를 1 MSS로 초기화하지만,

RENO 방식은 3duplicate acks에 대해선, 현재 네트워크 상태가 나쁜 것은 아니기 때문에, cwnd를 1/2로 줄입니다.

 

 

 

2.2 Congestion Avoidance

기존에 slow start에서는 매 RTT마다 cwnd가 2배로 늘어난다고 했습니다.

하지만 이렇게 지수증가를 하게 되면, 어느 시점부터는 너무 많이 증가해버려 congestion을 유발할 수도 있습니다.

따라서, ssthresh라는 임계값을 두어, ssthreash에 도달했을 때, CA 상태로 들어가게 됩니다.

 

CA 상태로 들어가면, cwnd를 1씩 선형 증가시키게 됩니다.

 

 

 

ssthreash 값은, loss가 발생했을 때 cwnd의 값의 1/2로 설정됩니다.

 

 

 

2.3 Fast Recovery

 

fast recovery는 RENO 방식에만 존재합니다.

3duplicate ACKs 가 생겼을 때, cwnd를 1 MSS로 떨어뜨려 버리면, 현재 네트워크 상태는 좋은데 cwnd가 작아서 성능이 떨어질 수 있습니다. 

따라서 ssthresh 값에서 3만큼 더한 값으로 cwnd를 설정하게 됩니다.

• +3인 이유는? : duplicate ack 3개가 왔다는 것은, inflight 상태로 간 3개가 존재한다는 뜻이기 때문

 

 

간단하게 FSM을 정리하자면, 아래와 같습니다.

1. cwnd = 1MSS로 시작하여, slow start 상태에서 2배씩 cwnd가 증가합니다.
2. ssthresh값에 도달하게 되면, congestion avoidance 상태로 들어가서, 1씩 cwnd가 증가합니다.
3. 만약 3 duplicate ack가 발생하면, fast recovery 상태로 들어가서 duplicate ack마다 1씩 cwnd를 증가시킵니다.
4. fast recovery에서 다른 ack가 오면, 상태를 탈출하여 다시 CA 상태로 갑니다.
5. 만약 loss가 생겨 timeout이 걸리게 되면, cwnd = 1 mss로 설정하여 slow start로 다시 시작합니다.

 

 

 

2.4 TCP fairness

TCP 방식은 공평합니다. 왜 공평할까요?

 

서로 다른 host가 서로 다른 throughput을 가지고 시작한다고 하겠습니다.

각자 throughput이 1씩 증가하다가, 어느 순간 congestion이 발생합니다.

congestion이 발생하면 cwnd가 1/2로 되므로, throughput도 1/2로 됩니다.

이 과정이 반복되게 되면, 각각의  호스트가 동일한 throughput을 가지는 값에 수렴하게 됩니다.

 

 

 

본 글은 Computer networking : a top-down approach 라는 책을 통해 작성되었습니다.