전송계층(4) _ Congestion Control

 TCP Congestion Control 

• congestion control은 네트워크 상황에 의해 결정됨
• 네트워크 상황에 따라 조절

데이터는 네트워크를 거쳐 전달된다.

라우터마다 수용할 수 있는 Queue의 길이가 정해져 있기 때문에, 데이터를 보낼 때는 상대의 recv 버퍼 상태뿐만 아니라 네트워크 상태도 고려해야하 한다.

 

 

❓ 데이터를 전달할 때 버퍼, 네트워크 한계 둘 중 어느 쪽에 맞추어야 할까?

 

❗ 상태가 더 안 좋은 쪽에 맞춘다

• 네트워크가 20byte만큼, 상대의 recv 버퍼가 10byte만큼 감당 할 수 있을 때
  • 상대의 recv만큼 전송할 수 있다
• 네트워크가 5byte만큼, 상대의 recv 버퍼가 10byte만큼 감당 할 수 있을 때
  • 네트워크 한계 만큼만 전송할 수 있다

무형의 네트워크를 측정해야하는데 이는 공용 자원의 영역

만약 네트워크 처리율이 낮아진 경우

host는 자신이 보낸 데이터에 대한 ACK를 유효한 시간 내에 받지 못하였으므로 재전송

이 현상이 계속 반복되면 네트워크에 부하를 주게 됨

결국엔 collapse가 발생
collapse: 네트워크 혼잡 때문에 패킷이 손실되면서 연결의 성능이 급격히 악화되는 현상

TCP가 성공적으로 수행되기 위해서는 네트워크에 부하를 주지 않게끔 동작해야함

TCP의 메카니즘을 수행하기 위해서는 네트워크 상황을 고려해야하는데 그걸 성공적으로 하기위해 congestion control 개념이 나옴

congestion control은 TCP라는 통신을 수립한 Host간의(peer-to-peer) reliable을 성공적으로 수행시키기 위해 이기적으로 전제되는 동작이지만, 결국에는 전체적 환경인 네트워크를 파괴시키지 않는 쪽으로 기술이 발달된 과정

반면 UDP는 congestion control을 수행하지 않음

reliable을 보장하지 않기때문에 재전송 같은 네트워크 부하가 되는일 자체를 안함

네트워크의 상황이 좋은지 안좋은지 판단 근거

 

1️⃣ End-to-End congestion control

• TCP를 수립한 두 Host가 네트워크 상황을 유추하여 congestion control을 수행하는 방식
• 현재 TCP가 congestion control로 채용하는 방식
• sender는 delay나 loss에 따라 sender buffer의 window size를 동적으로 변화시킴

2️⃣ Network-assisted congestion control

• 각각의 라우터들이 TCP를 수립한 host 에게 queueing delay 들이 어떤지 정보를 제공하는 방식
• 이론적으로만 이야기 되는 것

---

 3 main phases 

1️⃣ Slow Start

• 제일 처음 작은 데이터를 전달하며 네트워크가 처리 가능한 용량까지 점차 데이터 크기를 늘린다
• 전달 데이터는 exponentialy하게 증가한다
• 병목 현상이 생길 수 있으므로 제일 처음 작게 보내는 것

 

2️⃣ Additive increase

• exponentialy하게 증가하다가 임계점(threshold)을 만나면 additive하게 증가한다

 

3️⃣ Multiplicative decrease

• 패킷 로스가 일어나면 window size를 절반으로 줄여버림

 

❓ 왜 늘릴때는 조심스럽게 늘리면서 줄일 때는 과격하게 줄이느냐?

 

❗ 네트워크는 공유 자원이고 네트워크 병목현상이 발생했다면 조금씩 줄여서는 풀리지 않는다. 다같이 전송량을 확 줄여야 막힌 네트워크가 풀릴 수 있기 때문에 패킷 로스가 발생 했을 때 multiplicative로 줄이는 것이다!

---

 details 

congestion control에서 전송하는 데이터 양의 단위

• MSS
  • Maximum Segment Size
  • Additive increase → 매 RTT 마다 1 MSS ^ 2 씩 window size 증가
  • Multiplicative decrease → 패킷 유실 시 window size 절반으로 감소
• 이 과정에서 생기는 다이어그램이 톱날과 비슷해서 Saw Tooth Behavior 이라고도 함

 

전송속도

• CongWin이 변동이 심함
• 그래서 전송속도는 RTT보다 CongWin에 좌우됨
• congestion window size를 결정하는건 네트워크
• 네트워크 상황에 따라 congestion window size 가 결정이 되고 이거에 따라 속도가 결정이 되기 때문에 네트워크 상황에 따라 우리의 속도가 결정 되는 것

 

congestion control의 두 가지 버전

• TCP에서 패킷 유실을 탐지 하는 경우
  • timeout 현상이 발생했을 때
  • 3 dup ACK 일 때
• 1세대 Tahoe는 일단 패킷 유실이 발생하면 무조건 1MSS로 다시 되돌아와 Slow start부터 시작함
• 그러나 이 두 경우의 네트워크 상황은 다를 수 있음
  • timeout
    • 네트워크가 안 좋은 상황
  • 3 dup ACK
    • 다 잘 가는데 운나쁘게 하나만 없어진 상황
    • 네트워크는 잘 운영되는 상태

⇒ 각 경우에 따라 네트워크 상황이 다르니 행동을 달리 해야함! → 2세대! Reno

✨ 2세대 Reno는 timeout 시 Tahoe와 같이 Threshold은 절반으로 줄어들고 window size는 1MSS로 다시 되돌아오지만(slow start부터 시작)
3 dup ACK의 경우에는 네트워크의 과부하로 보기 어려우므로 Threshold은 절반으로 줄어들고 window size를 Threshold로 설정하고 additive increase 부터 통신한다

---

 TCP Fairness 

 

• K개의 TCP 연결 디바이스들이 R bps의 대역폭을 가지는 병목 링크(Bottleneck Link)를 공유한다면, 각 연결의 평균 전송률을 R / K 에 가깝게 맞춘다면 congestion control 매커니즘은 공평하다고 볼 수 있다

 

해당 링크를 먼저 사용하고 있던 디바이스가 더 높은 속도를 가질 수는 있다. 하지만 다른 디바이스가 들어오고 패킷 유실이 발생하기 시작하면 Multiplicative Decrease를 실시하면서 모든 디바이스의 속도가 절반으로 줄어든다. 이 과정을 반복하며 속도를 늘리고 줄이다 보면 결과적으로 공평하게 쓸 수 있게 된다.