TCP #3 Flow Control & Congestion Control

흐름 제어: 수신자 측에서 문제가 생기는 경우(버퍼가 꽉 차서 패킷 손실)

혼잡 제어: 네트워크 상에 문제가 생긴 거(라우터 큐가 꽉 차서 패킷 손실 / 큐에서 나갈 때까지 딜레이가 긴 경우)

 

송신자가 이 두개를 구분할 수 있을까?

할 수 있다

 

받는 쪽에서 문제가 생기는 건 헤더에 recieve window(rwnd)값을 보고 어느정도 알 수 있다.

네트워크에 문제가 생기는 건 IP 계층의 도움을 받아 가능하다.

* 라우터에서 문제를 파악하면 IP의 ECN을 활성화하고

* 수신 측에서는 TCP의 ECE를 1로 바꿔서 아크를 보내면 네트워크에 문제가 있다는 것을 파악 가능

 

구분이 가능은 한데, 문제는 두가지 문제에 따로 대처하기 보다는 같이 대처한다.

일단 설명은 두 가지로 나눠서 가능하다.

---

TCP Flow Control

 

수신자 관점 버퍼

R c v B u f f e r		Buffered Data
	r w n d	Free Buffer Space

RcvBuffer : 전체 버퍼 사이즈

- 기본 4096바이트, OS가 필요하면 조절

rwnd: 패킷을 받을 수 있는 버퍼 크기

- 송신자는 아직 ACK를 받지 않은 패킷의 수를 rwnd보다 작게 유지 => 수신자 버퍼의 오버플로우 방지

* ACK 안받은게 한번에 도착해버리면 rwnd가 감당을 못함

 

슬라이딩 윈도우 (Sliding Window)

수신 측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답없이 전송할 수 있게 하여 흐름을 동적으로 조절하는 제어 기법

=> 패킷 전달이 확인되는대로 윈도우가 옆으로 슬라이딩

 

송신 윈도우 크기: ACK를 받지 않은 패킷들의 크기와, 패킷을 보낼 수 있는 버퍼의 크기를 합친 것

송신 버퍼의 범위는 수신 측의 여유 버퍼 공간을 반영하여 동적으로 바뀜

 

비정상 윈도우 신드롬 (Silly Window Syndrome)

네트워크 속도도 느린데 1바이트 보내려고 40 바이트 헤더 붙여서 보내는 건 비효율적일 것

-> 모아서 보낸다

예시) 텔넷

 

Nagle 알고리즘

- 응용 프로그램에서 받은 데이터가 최대 세그먼트 크기(MSS, Max Segment Size)면 전송

- 수신 측으로부터 확인 응답을 받을 경우 전송 => 확인 응답이 올 때까지 전송할 데이터를 모아두고 보냄

- 타이머가 완료된 경우 전송

 

... 물론 네트워크 속도가 빠르면 안모으고 그냥 보내도 된다

 

대용량 데이터

- 수신측의 처리 속도에 따라 송신측의 전송 속도 제어가 필요 => 윈도우 기법

- 확인 응답을 수신할 때까지 전송할 수 있는 데이터 양을 윈도우로 조절

 

 

슬로우 스타트 (Slow Start)

송신측에서 네트워크 상태에 따라 흐름을 제어

 

윈도우 크기 = min(rwnd, 혼잡 윈도우 크기)

혼잡 윈도우 크기: 처음에는 1로 시작해서, 다음엔 2, 4, 8, 16.. 2의 n승 형태로 보내는 크기가 증가

바이트 길이를 잰다고 하면 2**i * MSS

 

혼잡(Congestion)

망에 입력되는 트래픽 양이 망이 처리할 수 있는 한도를 초과

해결책

1. 네트워크 망을 확장한다

2. TCP.. 인데 완전한 해결은 어려움. 하위 계층 전반적인 문제

 

혼잡 제어 (Congestion control)

많은 호스트가 너무 많이, 동시에 보내서 네트워크가 다루기 힘든 경우의 제어이다.

- Lost pakects (라우터에서 버퍼 오버플로우)

- Long delay (라우터 버퍼의 큐잉 시)

 

혼잡 제어 발전에 따라

1. TCP Tahoe(88)

2. TCP Reno(90)

3. TCP NewReno(99)

 

해결 방법

- 고전적인 TCP 독자 해결 (End-to-end)

- 최근의 네트워크 도움받는 방식 (Network-assisted)

라우터가 TCP에 피드백을 제공(ECE, ECE..)

 

혼잡 제어 방식

- 예방적(Preventive) 혼잡 제어

사전에 데이터 양을 조절, 패킷 전송 시 계약에 따라 패킷의 전송 순위를 결정(Priority Control)

 

- 반응적(Reactive) 혼잡 제어

네트워크에서 체증이 발생할 때마다 트래픽 감소

패킷의 지연 시간, 라우터의 버퍼의 길이 등을 계속 측정 -> 혼잡 정도를 초기에 발견하고 제어

 

Congestion의 발견

- 타임아웃...심각한 경우

- 연속적인 중복 아크(3개)...심각하진 않은 경우

 

Congestion에 대한 대응

- 트래픽을 과도하게 유발하는 호스트들이 혼잡이 해소될 때까지 패킷 전송을 조절

 

원래 혼잡 제어는 라우터에서 하는게 맞다

그런데 라우터는 일이 많고 TCP는 엔드에서만 작동하니 일을 좀 대신 하는 형태

 

 

Awnd (Advertised window).. 흐름 제어

- 초기 연결 설정 시에는 최대 버퍼 사이즈(초기 Awnd)를 알려줌

- 패킷을 수신할 때마다 자신의 버퍼 중 비어있는 공간의 크기(Awnd)를 알려줌

- rwnd와 같다고 보면 됨

 

Cwnd (Congestion window).. 혼잡 제어

- TCP가 패킷을 전송할 때 ACK를 받지 않고 연속해서 보낼 수 있는 패킷의 양을 결정

 

흐름 제어를 위해서는 Awnd만큼 패킷을 전송할 수 있는데,

혼잡 제어를 위해서는 Cwnd만큼 패킷을 전송할 수 있음

 

초기 cwnd는 1이고, 아크를 받을 때마다

cwnd = 2**i   until min(cwnd, awnd)

계속 증가하다 문제 없으면 awnd까지 도달할 것

 

=> 흐름 제어와 혼잡 제어는 동시에 같이 작동

 

AIMD (additive increase, multiplicative decrease)

cwnd 손실이 일어날 때까지 1씩 증가, 손실 발생 시 절반

원칙은 이건데 2**i 로 사용하기도 하고,

TCP 버전마다 좀 다름

 

TCP Tahoe 기준

손실 발생 시,

1. Threshold를 cwnd의 절반으로 설정

2. 그리고 cwnd를 1 MSS로 줄여버리기

3. cwnd가 스레스홀드보다 커지면 congestion avoidance

 

스레스홀드 이후부터는 혼잡 위험이 있다고 판단하고 cwnd를 1씩 증가시킴

이게 congestion avoidance

 

TCP Reno

타임아웃 => 심각한 상태라 판단하고 Tahoe처럼 대응

중복 아크 3개

- Fast Transmit 하고

- Fast Recovery

cwnd를 반으로 자르고 바로 1씩 증가 (바로 congestion avoidance 구간)

상태가 심각하지 않다고 보는 것

 

TCP NewReno

보통 혼잡은 연속적으로 일어나는데,

cwnd나 스레스 홀드를 계속 반으로 자르면 복구가 오래걸림

=> 사건이 일어난 시점의 윈도우 사이즈 내에서 또 문제가 생기면 윈도우 크기를 줄이지 않도록 설정

---

+) 여러 호스트의 TCP의 cwnd 사이즈 변화

결론부터 말하면, 최근에 들어온 사용자랑 전부터 있던 사용자가 비슷해짐

 

1번 사용자: cwnd 20 스타트

2번 사용자: cwnd 4 스타트

 

20 -혼잡-> 10 -> 16 -혼잡-> 8 -> 14 -혼잡-> 7 -> 13 -> 6 ....

4   -혼잡-> 2   -> 8   -혼잡-> 4 -> 10 -혼잡-> 5 -> 11 -> 5 ....

결과적으로는 점점 비슷해지게 됨