[네트워크] 전송계층 - TCP 혼잡 제어

네트워크의 혼잡 상황을 고려해서 보내는 데이터의 양을 조절

Congestion Control의 원리

congestion

• 네트워크가 처리할 수 있는 것보다 더 많은 데이터가 들어왔을 때 생기는 현상
• 라우터에서 패킷 유실이 일어날 수 있다
• 라우터에서 딜레이가 길어질 수 있다

재전송 상황

• 패킷 유실로 판단된다면 재전송
• 유실 안돼도 딜레이 생겨서 타이머 터지면 재전송
  -> 많이 보내서 막힌건데 다시 보내고 있음 (보낸 양이 더 많아짐). 상황을 악화시키는 TCP의 동작

• 보내는 데이터의 양을 점점 늘려도 특정 시점 이후에는 오히려 받는 데이터의 양이 줄어든다.
• 모든 애플리케이션이 많은 양을 보내면 혼잡 발생. 네트워크는 공유자원이기 때문에 조금씩 나누어 보내야 함

---

TCP 혼잡제어 동작

• TCP는 피드백(ACK)에 근거해서 네트워크 상황을 추측하고, 그에 따라 동작한다.

패킷의 윈도우 사이즈에 영향을 미치는 요인

• receiver window : 리시버 버퍼가 받아들일 수 있는 데이터 공간 (남은 공간)
• congestion window : 네트워크가 받아들일 수 있는 데이터의 양

window size는 이 둘 중 작은 값으로 setting된다.

따라서 TCP 혼잡제어의 핵심은 congestion window 사이즈를 어떻게 제어하는가이다.

---

additive increase (조심스레 늘린다)

• 항상 window size를 MSS(Maximum Segment Size)로 설정한다.
• 세그먼트를 보내고 피드백(ACK)을 받으면 1 MSS씩 윈도우 사이즈를 늘린다

multiplicative decrease (1/2로 줄인다)

• 윈도우 사이즈를 늘리다가 네트워크 상황 악화로 유실이 감지되면(피드백이 오지 않음) congestion window size를 절반으로 줄인다.
• 절반으로 줄이는 이유 : 보내는 속도를 늘릴 때는 조심스레 늘려야 하지만(네트워크는 다같이 쓰는 공유자원이니까), 문제가 생겼을 때는 확 빼야 해결된다.

---

Slow Start

• segment를 제일 처음 보낼 때는 congestion window size를 얼마로 설정해야 할까?

• 제일 처음 시작할 때 congestion window size는 1 MSS로 설정한다. (공용 자원이기 때문에 조심스럽게 접근)
• 피드백이 잘 오면 지수적으로 증가시킨다. (2의 n승)

Slow Start Thrashold

• Slow Start Thrashold를 설정해놓고, 그 이상 넘어가게 되면 이후부터는 slow start가 아니라 additive increase phase가 된다.
• 경험적으로 Slow Start Thrashold 이후부터는 congestion이 발생할 구간이기 때문에 slow start를 유지하지 않고 additive increase로 변경하는 것
• 이를 congestion avoidance라고 한다.

congestion avoidance

패킷 유실로 판단하는 상황

• Timer expire
• 3 duplicate ACKs

이 중 3 duplicate ACKs 상황이 더 혼잡하다. 따라서 상황에 따라 다르게 대응할 필요가 있다.

TCP Tahoe - Timer Expire 상황

• 유실을 감지해 네트워크 상황이 안좋다고 판단되면, 윈도우 사이즈를 처음 상황인 1 MSS로 다시 설정해 처음부터 다시 시작한다.

TCP RENO - 3 duplicate ACKs 상황

• 이 경우는 Timer Expire만큼 심각하지 않으니 큰 손실을 감당하면서까지 윈도우사이즈를 1MSS로 줄일 필요는 없음.
• 유실 발생 지점에서 window size와 Slow Start Thrashold를 절반으로 줄인다.