Tcp_ congestion control / fairness

Congestion control 

 

   수신 측의 처리 속도에 따라 송신 속도를 제어하는 서비스가 flow control이라면, congestion control은 네트워크 상황에 따라 송신 속도를 제어한다. 

 

   네트워크 내에 많은 사용자가 자원을 사용하거나 너무 많은 데이터가 라우터에 들어와 네트워크 자체의 혼잡도가 올라감에 따라 전송 패킷의 지연 또는 라우터의 오버플로우가 야기된다. 

 

   flow control 처럼 단순히 남은 버퍼 상태를 세그먼트에 표시하여 지속적으로 주고 받는 것을 없는 것이, 네트워크의 상황은 송신 측에서 쉽게 알 수 없고, 계속 변하기 때문에 값을 하나로 유지할 수 도 없다. 이러한 상황에서 네트워크의 현 상황을 지속적으로 유추해서 송신 속도를 최대한의 네트워크 성능과 맞추는 것이 congestion control의 목표이다.   

Congestion control, Tahoe 방식과 Reno 방식

   위 그림은 현재 네트워크 상황을 모르는 상태에서 Congestion control 방법을 보여준다. 먼저 네트워크 상황을 모르기 때문에 작은 값부터 전송하기 시작한다. 너무 작은 값으로만 진행되면 네트워크의 성능을 낭비하는 경우 발생한다.

 

   데이터를 아주 작은 단위(window size) 부터 전송하기 시작하되 그 크기를 급격히 증가시키다가 위험한 지점이라고 여겨지는 점(threshold) 값을 넘어서면 그때부터는 크기 변화를 작게하여 천천히 사이즈를 변화시켜가면서 데이터를 전송한다. 

 

   loss가 발생하면 현재 threshold 값의 1/2을 하여 다음 threshold를 지정하고, 다시 작은 값부터 시작해서 크게 증가를 반복하게 된다. 

Loss 상황: time out / duplicated ack

   Loss를 확인하는 방식으로는 time out과 duplicated ack 두가지가 있다. time out 상황은 이후 송수신 여부를 전혀 확인 할 수 없는 네트워크 지연/불능 상황으로, Duplicated Ack는 소수의 패킷만이 loss된 상황에서 다른 응답은 확인이 가능한 상태이므로 불능 상황은 아님은 확인 할 수 있다.

 

   따라서 이 두가지 경우를 나눠 loss가 발생했을 시 아예 불능 상황인 time out에서는 congwin 사이즈를 아예 처음부터 작은 값으로 시작하여 큰 단위로 증가하고 (Tahoe 방식), 그렇지 않은 duplicated ack 상황에서는 threshold만 수정하고 그 threshold부터 다시 천천히 크기를 증가시켜 (Reno 방식), 더 효율적인 congestion control을 가능하도록 한다.

 

Fairness

 

   여러 채널이 한 네트워크를 사용한다면 사용하는 자원은 공평하게 분배된다. 위 congestion control을 따르면 여러 채널이 사용해도 자원은 공평하게 분배되어 최적으로 사용된다. 두 채널이 서로 다른 초기 윈도우 사이즈를 갖고 한 네트워크를 사용할 때를 예시로 공평한지 확인한다.

 

fairness

   위는 채널 1,2가 서로 다른 시작 윈도우 크기에서 시작하여 loss 시 1/2에 줄어 다시 작아져도 이를 반복하면 결국 두 채널 윈도우 사이즈 모두 평균 값에 수렴하는 모습을 보여준다.

 

Note