7. TCP 혼잡제어

본 내용은 Computer networking : a top-down approach 책을 바탕으로 정리하였습니다.

 

Index

• 1. 혼잡 제어의 원리
• 2. TCP 혼잡제어

 

1. 혼잡 제어의 원리

 

TCP가 어떻게 혼잡 제어를 하는가? 에 대해 알아보기에 앞서, 혼잡 제어가 무엇이고 어떤 상황이 발생할 수 있는지 먼저 알아보도록 하겠다.

 

1.1 혼잡이란?

 

혼잡이란 네트워크가 감당하기에는 많은 송신자가 너무 많은 패킷을 너무 빠르게 보내 발생하는 현상을 의미한다.

이는 흐름 제어와는 다른 것으로 네트워크의 감당여부가 중요하다.(흐름 제어는 송신자와 수신자의 속도 차이를 해결하기 위한 기법)

 

1.2 혼잡의 3가지 시나리오

 

1) 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터

 

 

 

첫 번째 상황은, 라우터의 버퍼가 무한대인 상황이며 당연히 실제로는 없는 이상적인 경우이다.

 

두 호스트 A, B는 λ(in) 바이트/초의 속도로 라우터에게 제공하고, 그에 대한 서버의 처리량은 λ(out)이 되겠다.

 

이 경우 A, B가 보낼 수 있는 최대 속도로 전송을 해도, 라우터의 버퍼는 무한대이기 때문에 보내는 족족 언젠가는 다 오게 되어있다. 덕분에 재전송도 없을 것이다.

 

연결 성능

 

 

 

첫 번째 시나리오에서의 연결 성능을 나타내는 그림이다.

 

왼쪽 그래프는 연결 전송률의 함수로 연결당 처리량을 그린 것이다.

두 개의 호스트가 동시에 보내므로, 출력 링크의 가능한 출력량 R을 2로 나눈 값이 올바른 전송률이 되며,

전송률이 R/2 이상일 때, 처리량은 단지 R/2가 될 뿐이다. (성능은 그대로라는 의미이다.)

 

오른쪽 그래프는 연결당 지연을 그린 것이다.

라우터의 버퍼가 무한대라고 가정했기 때문에 빠른 속도로 계속 보내면 라우터의 버퍼에 무한대로 쌓이게 되며,

위 그래프처럼 딜레이가 아주 크게 증가하게 된다.

 

2) 시나리오 2 : 2개의 송신자, 유한 버퍼를 가진 하나의 라우터

 

 

두 번째 시나리오는 라우터의 버퍼가 유한하다는 설정을 가진다. 

 

이 경우 버퍼의 오버플로우가 발생할 수 있으며, 만약 오버플로우 발생 시 재전송이 필요하다.

 

추가로 두 번째 시나리오는 3가지 가정을 갖는다.

 

(a). 호스트가 라우터의 버퍼가 비어 있는지 아닌지를 알고, 버퍼가 비어 있을 때만 패킷을 송신한다.

-> 이 경우 시나리오 1처럼 어떠한 손실도 발생하지 않고 처리량은 λ(in)과 같다.

 

(b). 호스트는 패킷이 손상된 것을 알았을 때만 재전송한다.

 

 

-> 이 경우 라우터에서 버려진 패킷에 대해서만 재전송을 하고, 처리되기 때문에 점차 R/2에 가까워지는 구조이다.

 

(c). 유실을 모르고, 타임아웃을 통해서 알게 된다.

 

 

-> 이 경우 타임아웃에 따른 지연으로 인해 송신자의 불필요한 재전송(duplicate)이 생기면서 처리량이 줄어들게 된다.

타임아웃이 발생하면 중복된 패킷을 다시 보내는데, 이 때 원래 보낸 패킷도 수신측에 도착하기 때문에 수신측에서 중복된 패킷이 버려지게 되고 따라서 수신측에서는 처리량이 감소하게 되는 것이다.

 

* goodput 이란? 시나리오 1처럼 R/2 만큼의 출력이 수신되는 아주 좋은 처리량을 의미한다!

 

 

3) 시나리오 3 : 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로

 

 

 

 

가장 현실적인 시나리오이다. 여러 개의 호스트와 멀티홉이 존재하는 경우이며, 4개의 호스트는 겹쳐지는 홉 경로를 통해 패킷을 전송한다. 이때 타임아웃/재전송 방식을 사용한다고 가정한다.

 

만약 A -> C, B->D로 각각 패킷을 전송한다고 했을 때, 서로 같은 멀티홉을 지나가는 순간이 존재하기 때문에

서로의 경로에 영향을 받게 된다. 즉, 너무 많은 패킷을 보내려다가 둘 다 못 보낼 수 있다는 뜻이다.

 

시나리오 3에 대한 해결방안

 

1) 종단 간의 혼잡 제어

• IP 계층이 네트워크 혼잡에 관해서 종단 시스템에게 어떠한 피드백도 제공하지 않으므로 TCP가 수행해야 한다.
• 타임아웃, 딜레이가 나타날 때 TCP 세그먼트의 손실은 네트워크 혼잡 발생으로 생각할 수 있다.
• 추가로 TCP는 그에 따라서 윈도 크기를 줄인다.

2) 네트워크 지원 혼잡 제어

• 라우터가 송신자에게 직접적인 피드백을 제공한다.
• ex) ATM ABR, ECN, SNA

 

1.3 네트워크 지원 혼잡 제어의 예 : ATM ABR 혼잡제어

 

ABR은 available bit rate의 약자로서 간단히 말하면, 보낼 수 있는 양만 보내겠다는 의미이다.

 

네트워크의 부하가 적을 때, ABR 서비스는 여분의 가역폭을 이용할 수 있고,

네트워크가 혼잡할 때, ABR 서비스는 미리 정해진 최소 전송률로 억제할 수 있다.

 

 

 

위 그림은 ATM ABR 혼잡 제어의 중요 요소인 RM cell을 설명하기 위한 그림이다.

 

RM cell

 

RM은 resource management의 약자로, 제어를 위한 패킷을 의미한다.

위 그림처럼 data cell 사이사이에 RM cell을 넣고, RM cell 내부에는 2 바이트의 ER(감당할 수 있는 전송률) 필드가 있어

호스트와 스위치 사이에서 혼잡 관련 정보를 운반하는 데 사용된다.

 

하지만 그전에 data cell이 먼저 도착해버려 전송률을 초과할 경우가 생기는데 이때를 위해서 data cell 내부에는

EFCI라는 비트가 있다. EFCI 비트는 간단하게 혼잡 신호를 보내기 위한 비트라고 알면 된다.

 

 

2. TCP 혼잡 제어

 

앞서 배운 것처럼 TCP는 신뢰성을 중요시하는데, 그 요소들 가운데 혼잡 제어 메커니즘이 있다.

 

특히 아까 말한 것처럼 IP는 아~~ 무것도 지원하지 않기 때문에 특히 TCP는 종단 간의 혼잡 제어를 사용해야 한다.

즉, 송신자가 스스로 혼잡 상황에 맞춰 전송률을 조절해야 한다는 것이다.

 

2.1 TCP 혼잡 제어의 기본 원리

 

AIMD (Additive Increase Multiplicative Decrease)

-> 증가할 때는 점진적으로 늘어나고, 감소할 때는 배로(지수적으로) 줄어든다.

 

• additive increase : 손실이 감지될 때까지 매 RTT마다 1 MSS씩 증가한다.
• multiplicative decrease : 손실 발생 후 절반으로 줄어든다.

뭐가 자꾸 증가하고 줄어든다는 것일까?

-> TCP 혼잡 제어 메커니즘은 추가적인 변수인 혼잡 윈도(cwnd)를 사용하여 트래픽 전송 비율을 제한한다.

 

 

이전 포스팅에서 설명한 rwnd가 수신자 버퍼 공간이라면 송신자에겐 cwnd가 있다. 둘 다 의미는 비슷하다.

 

위 그림처럼, 보냈지만 아직 확인 응답받지 못한 "in-flight"는 이전엔 rwnd보다 크면 안 된다고 했지만

이제 cwnd도 나왔기 때문에 min(cwnd, rwnd) 보다 크면 안된다고 바꾸어 생각해보자

 

TCP 전송률

송신자가 cwnd 바이트 크기의 data를 보냈을 경우 RTT를 기다리면 전송률은 cwnd/RTT 가 된다.

 

 

2.2 TCP slow start

 

아까 위에서 TCP 혼잡 제어는 cwnd가 증가할 때 점진적으로 증가하면서 1 MSS씩 더해진다고 했었다.

 

하지만 TCP slow start 방식은 시작 후 증가율이 지수적으로 증가하게 된다(손실 발생 전까지)

 

지수적이라는 단어를 을 쓰다 보니 생각난 건데.. 새벽에 심심해서 잡소리를 하자면..

어릴 때 읽은 책 내용 중에 아주 옛날~옛날에 주인과 노비가 있었는데, 이 노비가 영특해가지고 어느 날

주인에게 "오늘부터 하루 일당을 쌀 한 톨씩 받을 테니 하루가 지날 때마다 2배씩 늘려주세요!"라고 했단다..

그걸 들은 주인은 "1톨 2톨 4톨 8톨... 개꿀인데?"라고 생각해서 얼른 수락했다.

하지만 한 달이 지나고, 1톨은 2^30 톨이 되어버렸고, 주인은 결국 자기 딸을 내어줬다는.. 슬픈 이야기다. 

아무튼..

TCP slow start도 초기 전송률은 느리지만, 점점 아주~ 빨라진다!

 

 

2.3 TCP 손실 발견 시 대응

 

대응 방식은 두 가지가 있는데, 각각 TCP Tahoe, TCP RENO라는 방법이다.

 

TCP Tahoe (예전 방식)

• 손실 발생 시 cwnd는 1부터 다시 시작한다.
• cwnd는 슬로 스타트 부분에서 지수로 증가하고, 이후 혼잡 회피 단계에서 점진적으로 증가한다.

TCP RENO

• 3개의 중복 ack을 받은 경우 cwnd를 절반으로 줄인다.
• 하지만 타임아웃은 1부터 다시 시작한다.

추가) 쓰레쉬(ssthresh)

• 슬로 스타트 임계치의 약자로 여기서 보통 cwnd/2로 정한다.

2.4 Fast Recovery

 

빠른 회복에서 cwnd 값은 잃었던 세그먼트에 대한 매 중복된 ACK를 수신할 때마다 1 MSS씩 증가된다. 

이는 아직 중복된 ACK에 대한 세그먼트를 받지 못했어도, 계속 cwnd를 증가시켜 손실 이후 빠른 회복을 도모한다.

 

 

2.5 요약 : TCP 혼잡 제어

 

 

 

순서

• 1. 초기에 slow start에서 시작하며 거꾸로 된 V 모양처럼 변수를 초기화해준다.
• 2. ACK을 계속 받다가, cwnd가 ssthresh 이상으로 증가하는 순간 혼잡 회피 단계로 이동한다.
• 3. 혼잡 회피 단계에서는 새로운 ACK에 대한 cwnd 증가량이 점진적으로 늘어나게 된다.
• 4. 만약 중복 ACK을 3개 받았다면 ssthresh와 cwnd가 줄어들며 빠른 회복 단계로 이동한다.

순서는 다양하게 바뀔 수 있으며, 여기서 timeout 상황은 세 군데 모두 동일하다.

 

 

2.6 TCP 공평성

 

TCP는 신뢰적인 프로토콜이므로 호스트 별로 공평한 송신율을 가지고 있어야 한다.

 

왜 TCP가 공정한가?

 

 

위 그림은 두 호스트 간의 전송률에 따라 손실이 발생하면서 대역폭이 동등해지는 과정을 나타낸다.

하지만 그림이 좀 이해하기 어려운데, 의외로 좀만 생각하면 간단하다.

 

예를 들어 전송률 R을 갖는 하나의 링크를 공유하는 호스트 A, B가 있고, 각각에 대한 전송률이 C1, C2이고, R의 최대치는 15이다.

 

최초의 전송률은 C1 = 10, C2 = 2라고 하고, 그에 대한 합은 12이다.

아직 괜찮으니 1씩 더한다.

C1 = 11, C2 =3이고, 합은 14이다.

아직 괜찮으니 1씩 더한다.

C1 = 12, C2 = 4이고, 합은 16이다. 패킷 손실이 발생했으니 반으로 감소시킨다. C1 = 6, C2 = 2이다.

 

이런 식으로 점점 나가다 보면 결국엔 C1, C2는 비슷한 수치로 수렴하게 될 것이다. 방금 (10, 2)에서 (6,2)로 변한 것처럼 말이다.