카테고리 없음

[Network] Transport Layer - TCP Congestion Control

민트맛녹차 2023. 1. 22. 01:35

Congestion

network congestion 은 너무 많은 source 들이 데이터를 너무 빠른 속도로 보내 발생한다. congestion 은 router buffer 에 overflow 를 일으켜 lost packets 을 초래하고, router buffer 의 queueing 을 일으켜 long delays 를 초래한다.

router 에 대한 input packet 의 양이 증가하면 output packet 의 양도 증가하는 것이 이상적이다.

하지만, 현실의 network 는 router 의 buffer 는 finite 하고, multihop path 를 가지며 timeout 과 retransmission 이 일어난다. 이러한 특성들은 congestion 을 일으켜, input packet 의 양이 증가할 때 output packet 의 양이 증가하다가 일정 순간부터는 transmission capacity 가 낭비되어 output packet 의 양이 감소하게 되는 현상을 만든다. 따라서 packet 의 낭비를 막기 위해 적절한 congestion control 이 필요하다.  

 

TCP Congestion Control

IP layer 는 network congestion 에 관해 end systems 에 명확한 피드백을 주지 않기 때문에, TCP 는 network-assisted congestion control 이 아닌 end-to-end congestion control 을 사용한다. TCP 는 각각의 sender 가 네트워크로 트래픽을 보낼 수 있는 속도(rate) 를 제한하여 network congestion 을 인지하도록 한다. TCP sender 가 path 에 little congestion 을 감지하면 send rate 를 올리고, congestion 을 감지하면 send rate 를 감소시킨다. 이러한 방법에는 3가지 의문이 뒤따른다.

  • 어떻게 TCP sender 는 connection 으로 가는 트래픽의 속도를 제한하는가?
    • => TCP 는 네트워크로 트래픽을 보낼 수 있는 속도를 제한하기 위해, TCP sender 가  congestion window(cwnd) 라는 변수를 기록하도록 한다. 
  • 어떻게 TCP sender 는 path 에 congestion 이 있다는 것을 인지하는가?
    • => 과도한 congestion 이 발생하면,  router buffer 는 overflow 되어 datagram 이 drop 된다. dropped datagram 은 sender 에 loss event(timeout or the receipt of three duplicate ACKs) 를 일으켜 sender 가 congestion 이 발생되었다는 것을 알려준다.
  • send rate 를 바꾸기 위해 sender 는 어떤 알고리즘을 사용하는가?
    • => slow start, congestion avoidance, fast recovery. 앞의 둘은 필수이고, fast recovery 는 선택적이다. 

 

Slow Start

TCP connection 이 시작되면, TCP sender 는 cwnd 의 값은 1 MSS 에서 시작하여 매번 ACK 을 받을 때마다 1 MSS 을 증가시킨다. 즉, RTT 마다 cwnd 는 두 배가 된다. initial rate 는 늦지만 지수적으로 빠르게 증가한다. 

만약 timeout 에 의한 loss event 가 발생하면 congestion 의 가능성이 높으므로, TCP sender 는 cwnd 를 1 MSS 로 설정하고 slow start process 를 새롭게 시작한다. 또한 ssthresh(slow start threshhold) 라는 변수를 congestion 을 감지했을 때의 cwnd 의 절반으로 설정한다.

triple duplicate ACK 에 의해 loss event 가 발생하면 congestion 의 가능성이 비교적 낮으므로, TCP 는 cwnd 의 값을 절반으로 줄이고 ssthresh 의 값을 duplicate ACKs 를 받았던 때의 cwnd 의 절반으로 설정한다. 

cwnd 는 ssthresh  값에 도달하기 전까지는 두 배씩 증가하다, 값에 도달하면 slow start 는 끝나고 TCP 는 avoidance mode 로 전환한다. Congestion avoidance mode 에서는 TCP 는 cwnd 를 조심스럽게 증가시킨다. 

 

Congestion Avoidance

congestion-avoidance 상대에 들어서면, cwnd 의 값은 이전에 congestion 을 만났던 값의 대략 절반이므로 congestion 이 될 가능성이 높아진다. 따라서 TCP 는 RTT 마다 cwnd 의 값을 두 배씩 올리는 것이 아닌, 조금 보수적인 접근을 취하여 RTT 마다 single MSS 씩 증가시킨다.

 

Fast Recovery

fast recovery 에서는 TCP 가 fast-recovery state 로 들어가게 만든 missing segment 에 대한 duplicate ACK 을 받을 때 마다, cwnd 의 값이 1MSS 씩 증가한다. 결과적으로, missing segment 에 대한 ACK 을 받으면 TCP 는 cwnd 의 값을 줄이고(duplicate ACKs 를 받을 때의 cwnd 의 절반 + 3) congestion avoidance state 에 들어간다. 

fast recovery 는 TCP 의 구성 요소로 추천되지만, 필수는 아니다. TCP Tahoe 는 무조건 cwnd 를 1 MSS 로 줄이고, timeout 과 triple duplicate ACK 를 구분하지않고 loss event 발생 후에 slow start 단계에 들어간다. TCP Reno 는 fast recovery 를 포함한다.

 

TCP Tahoe and TCP Reno

initial threshold 는 8 MSS 이다. triple duplicate ACK event 가 일어나기 전까지는 Tahoe 와 Reno 는 동일한 동작을 한다. slow start 동안에는 cwnd 가 지수적으로 증가하고 threshold 에 도달하면 cwnd 가 선형적으로 증가한다.  triple duplicate ACK event 이후에는, loss event 가 일어날 때 cwnd 가 12 MSS 이므로 ssthresh 는 6 MSS 로 설정된다. TCP Tahoe 일 경우, cwnd 는 1 MSS 로 설정되고 ssthresh 에 도달하기 전까지 지수적으로 증가하고 도달 이후에는 선형적으로 증가한다. TCP Reno 의 경우 cwnd 가 9 MSS(6 MSS + 3 MSS) 로 설정되고 선형적으로 증가한다. 

 

AIMD

triple duplicate ACKs 에 의한 loss event 인 경우, TCP 의 congestion control 은 RTT 당 1 MSS 씩 선형적으로 증가시키고(additive increase) triple duplicate ACK evnet 에서는 cwnd 를 절반으로 줄인다(multiplicative decrease). 이러한 이유로, TCP Congestion Control 은 AIMD(additive-increase, multiplicative-decrease) 의 형태를 보인다. 

 

 

 

 

참조
Computer Networking _ A Top Down Approach, 7th, converted
저작자표시