TCP congestion control

패킷로스의 대부분은 라우터의 큐 오버플로우로 인해 발생한다.

따라서 ack이 오지 않는것을 congestion의 증거라고 추정한다.

 

ack이 돌아오지 않으면 네트워크에서 congestion이 발생한것으로 추정하고,

sender의 window size(한번에 보낼 수 있는 inflight packet 수)를 줄여 전송속도를 낮춘다.

 

1980년대 전까지는 congestion control이 적용되지 않았었다.

이 때는 패킷 드랍이 발생하면 재전송하도록 했기 때문에 네트워크가 더 혼잡해져 악순환이 일어났다.

 

 

 

sender의 윈도우를 cwnd라고 한다(congestion window)

이 윈도우는 혼잡에 따라 사이즈가 커지고 작아질 수 있다.

 

TCP rate = cwnd/RTT bytes/sec이다.

전송속도는 cwnd에 큰 영향을 받는다.

 

 

---

Congestion Control의 세 단계

1. slow start
2. congestion avoidance
3. fast recovery(option)

slow start: cwnd가 1부터 시작한다. ack이 오면 cwnd를 2배씩 증가시킨다.(1->2->4->8..)

(작은 수 1부터 시작하니까 slow start라고 지은듯. 하지만 2배씩 증가하니 빠르게증가함)

ssthresh(스레시홀드)에 도달하면, 이때부터는 linear하게 증가시킨다. 이 단계를 congestion avoidance라고 한다.

(ssthresh는 초기값을 64KB로 하도록 표준으로 설정한다)

 

어느 순간 ack 피드백이 오지 않으면(이는 slowstart 구간이나 congestion avoidance 구간 어디에서나 발생할 수 있겠다)

다시 cnwd가 1로 초기화되어 slow start단계로 돌아간다. 또, ssthresh값을 패킷로스가 발생한 시점의 1/2로 변경시킨다.

 

---

slow start

초기 cwnd = 1MSS(maximum segment size, 바이트단위)로 설정된다. 즉, 1개의 세그먼트 사이즈로 설정된다.

매 RTT마다 cwnd가 2배씩 증가한다.

실제 구현에서는 cwnd를 ack이 올때마다 1씩 증가시키면 된다.

 

congestion avoidance

매 RTT마다 cwnd가 1씩 증가한다.

실제 구현에서 cwnd는 ack이 올떄마다 1/cwnd MSS만큼 증가

 

그런데, ack이 오지 않는 경우는 2가지 있다.

1. timeout

2. 3-dup ACK

 

이 중 3-dup ACK은 중간에 하나의 패킷만 로스난것으로 볼 수 있다. 따라서 해당 경우에는 cwnd를 1로 초기화하는것이 비효율적일 수 있다.

 

따라서 3-dup ACK 상황에서는 Fast-recovery 단계로 진입한다

 

Fast-recovery단계는, 

ssthresh=cwnd/2로 변경하고, cwnd는 새로 갱신된 ssthresh+3 으로 변경된다. 이후, cwnd는 ACK을 받을 때마다 linearly하게 증가한다.

 

(3-dup ack과 timeout을 구별하는 것은 TCP의 새로운 버전으로 TCP Reno라고 부름. 기존의 구별하지 않는 TCP는 TCP Thahoe)

 

또, Fast-recovery단계에서 dupACK을 받을 때마다 cwnd를 1씩 증가시켜주는 것은 전송속도를 증가시키는것이 아니라, 유지시키기 위함이다. 왜냐하면 앞의 패킷이 로스가 났기 때문에 윈도우가 슬라이딩되지 못하고 멈춰있으므로, ack을 받을 때마다 cwnd를 1씩 증가시켜야 윈도우가 슬라이딩되는것처럼 작동한다. fast-recovery단계를 탈출하는 순간에는 새로 설정된 ssthresh값으로 cwnd가 설정된다.

 

---

따라서 sender는 혼잡제어와 흐름제어 모두 충족시키기 위하여 min(cwnd,rwnd) 만큼 패킷을 보내야한다.

 

 

---

TCP fairness

 

호스트들의 cwnd가 다른 상태에서 시작되더라도, congestion이 발생하면 기존의 cwnd가 큰 호스트가 더 많이 cwnd가 감소하기 때문에 시간이 흐름에 따라 호스트들은 공평하게 리소스를 가질것이다.

(하지만 공평하려면 RTT가 같아야 한다. RTT가 짧으면 더 빨리 cwnd가 증가하기 때문이다. 또, connection의 개수가 같아야한다. 한 호스트가 더 많은 TCP 세션을 만들어 사용하면 그만큼 더 많은 리소스를 가질것이다)

 

그와중 UDP는 congestion control이 없어서 UDP와 TCP사이는 공평하지 않을듯하다.