[NW] Congestion Control

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

드디어 네트워크의 마지막을 장식할 시간이 왔다. 그렇다고 큰 거는 아니고 스스로 계획해놨던 포스팅의 가장 마지막 포스팅까지 왔다는 것이다. TCP/IP를 전체적으로 다른 포스팅에 비해서 꽤나 자세하게 다뤄놓을 계획이었는데 그 마지막까지 온 것이다.

지난 번에 설명했듯이 이번 포스팅에서 설명할 이야기는 Congestion Control이다. Error Control, Flow Control에 이어 TCP의 중요 기능 중에 하나이다.  Congestion Control이란 무엇을 뜻하는 말인가? 말 그대로 혼잡을 제어하는 것이다. TCP는 신뢰성를 기반으로 하기 때문에 그 신뢰성을 만족시키면서 최고의 속도를 내기 위해 Congestion Control을 하는 것이다. 

TCP의 Congestion Control은 다음의 세 단계를 거친다.

Slow Start → Congestion Avoidance → Congestion Detection

마지막 Congestion Detection, 즉, Congestion을 탐지했으면 경우에 따라 Slow Start로 돌아갈 수도 있고 Congestion Avoidance로 돌아갈 수도 있다. 

각 단계별로 설명을 하기 전에 Congestion Control에서 직접적으로 다룰 window라는 것을 이야기해보자. 우선 100MB의 파일을 보낸다고 가정하자. 이 파일을 한 패킷에 넣어서 보낼 수 있을까? 당연히 불가능하다. 그래서 이것을 전송가능한 최대치로 나눈다. 그 최대치를 Maximum Segment Size 즉, MSS라고 한다. 이 사이즈대로 100MB를 아래와 같이 나눈다. 이제 sender의 TCP는 이 각각의 MSS를 receiver에게 보내면 된다. window는 TCP가 보낼 MSS 또는 보냈는데 아직 receiver로부터 ACK를 받지 않은 MSS들의 집합이라고 보면 된다. 아래와 같다.

위의 그림에서 MSS가 1MB라고 가정하여 100칸의 segment가 있다고 치자.(100MB를 보내야 하는 상황이므로) 그 중에서 30MB는 TCP가 보냈고 ACK도 받았다. 30MB부터 보낼 차례인데, TCP는 현재 window size를 10으로 두고 있다. 즉, 지금 현재 TCP가 작업할 segment는 30MB부터 40MB까지 10MB이다. 40MB부터 100MB까지는 아직 untouched 하게 내버려둔다. 자 지금 현재 TCP가 작업하고 있는 10MB 정도의 영역을 우리는 window라고 한다. 조금 더 정확히 말하면 opened window, 즉 열린 window이다. 지금 현재 이 부분으로 작업을 하고 있다는 뜻이다. 그렇다면 closed window는 어디일까? 0MB부터 30MB까지이다. 즉 지금 현재 이미 작업을 마친 부분을 의미한다. 

opened window 부분을 조금 더 자세하게 보자. 빨간 segment 들은 이미 receiver에게 전송을 마친 부분이다. 그러나 아직 ACK를 받지 않아서 opened window 에 포함되어있는 것이다. 주황색 segment들은 아직 receiver에게 보내지 않은 segment들이다. 40MB부터 100MB까지도 아직 보내지 않은 segment들이나 그 부분은 아직은 TCP가 신경쓸 부분이 아니므로 untouched하게 내버려둔다. (여기서 untouched라는 용어는 내가 표현하는 방법일 뿐이지 학술적으로 그렇게 설명하고 있는 용어는 아니다.) window size라는 것은 바로 여기서 말하는 opened window 안에 있는 segment 개수를 의미한다. 여기서는 10개가 되겠다.

자 이제 window 의 개념은 자세하게 설명한 것 같으니 TCP Congestion Control의 첫 단계 SLOW START를 공부해보자. 이 부분은 바로 window size를 1부터 시작하겠다는 뜻이다. 대신에 1부터 exponential 하게 증가하여 congestion window size(cwnd)가 1, 2, 4, 8, 16 .... 과 같이 기하 급수적으로 증가하게 된다. 이렇게 어디까지 증가하는가? ssthresh까지 증가한다. 이는 slow start threshold의 약자이다. 

이 값을 초과하기 전까지 Slow Start를 한다. ssthresh값이 16이라고 가정하고 시간에 따른 Slow Start의 전송량(단위;window)을 보자.

ssthresh값에 도달한 후에는 이제 더이상 Slow Start를 쓰지 말고 Congestion Avoidence를 쓰게 된다. Slow Start에서 window size를 두배씩 급격하게 늘려갔다면 Congestion Avoidence에서는 cwnd를 1씩 차근 차근 늘려간다. 위의 그래프를 이어서 그리면 아래와 같이 그려진다.

Congestion Avoidance는 TCP Timeout이 발생하거나 3 ACKs가 발생할 때까지 지속된다. 3 ACKs가 뭐냐고 물어보는 사람은 아래의 링크를 참고하라.

http://operatingsystems.tistory.com/entry/NW-Flow-Control-and-Error-Control

위의 링크에서 설명하는 3 duplicated ACK를 의미하는 것이다.

Congestion Avoidance는 TCP Timeout이 발생하거나 3 ACKs가 발생하면 멈춘다고 했다. 그 후에 진행되는 것이 Multiplicative Decrease이다. 이 과정이 위에서 말했던 Congestion Detection이다. TCP Timeout이 발생했을 경우에는 Multiplicative Decrease가 발생하면서 cwnd가 1이 되고 Slow Start 부터 다시 시작한다. 반면, 3 ACKs가 발생했을 경우에는 Multiplicative Decrease가 발생하면서 cwnd가 현재 cwnd의 절반이 된다. 그리고 Congestion Avoidance를 시작한다. 이를 그래프로 그리면 아래와 같다.

위의 모든 과정을 Algorithm으로 나타내면 아래와 같다.

요약하면 이러하다. TCP는 데이터를 보낼 때 Slow Start를 통해서 기하급수적으로 보내는 데이터의 양을 늘려간다. 그러다가 어느 수치에 다달으면(threshold) 보내는 데이터의 양을 Congestion Avoidance를 통해 서서히 즐가시킨다. 이 때 마주칠 수 있는 두 가지 경우가 있는데, 첫째로 Timeout이 발생하면 cwnd가 1로 되면서 Slow Start를 다시 시작하고 두번째로 3 ACKs가 발생하면 cwnd가 현재의 cwnd의 절반으로 되면서 Congestion Avoidance를 수행하게 된다.

이게 실제로 쓰이는지 궁금해 사람들을 위해 한가지 예시를 들어보자. 파일 다운로드 받을 때 전송 속도를 보면 답이 나온다. 처음에는 초당 수십 KB씩 받으면서 기하 급수적으로 초당 몇 MB 수준으로 올라온다. 그러다가 전송 속도가 줄었다 늘었다 한다. 그 과정이 결국 TCP의 Congestion Control 과정이다. 

아, 드디어 TCP/IP에서 내가 공부한 부분은 다 설명했다. 사실 하나 더 올리고 싶은 부분이 있다. TCP/IP 관련이 아니라 2계층인 Datalink layer 부분이다. 이 계층은 Error Correction을 지원한다. 즉, 전송 도중에 Error가 발생해서 올바르지 못한 데이터가 도착해도 receiver가 알아서 제대로 고친다는 뜻이다. 막 공부하고 싶어지지 않나?