3-6. 전송(Transport) 계층: TCP 혼잡 제어(Congestion control)

해당 글은 한양대학교 이석복 교수님의 과목 "컴퓨터 네트워크"를 공부하고 작성한 글입니다. 틀린 내용이 있으면 덧글로 지적해주시면 감사하겠습니다.

컴퓨터 네트워크 - 한양대학교 | KOCW 공개 강의

컴퓨터네트워크

 

---

혼잡 제어(Congestion control)

혼잡 제어(Congestion control)는 TCP의 주요 특징 중 하나이다.

그 개념이 왜 필요한지, 어떤 개념인지 알아보자.

 

1. 개념

A에서 B로 데이터를 보낼 때, 네트워크 상태는 데이터가 경유하는 라우터에 따라 달라진다.

만약 A에서 B로 데이터를 전송하면, 데이터는 바로 상대에게 날아가는 것이 아니라 네트워크를 거치게 된다.

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

 

데이터는 얼마까지 보낼 수 있을까? 버퍼, 네트워크마다 한계가 있다면 어느 쪽에 맞추어야 하는가?

 

1. 네트워크가 20바이트만큼, 상대의 recv 버퍼가 10바이트만큼 감당할 수 있을 때
=> 상대의 recv 버퍼 상태만큼 전송할 수 있음

위 상황의 경우 상대 end-system의 버퍼가 더 작으니 recv 버퍼의 상태에 초점을 두어 10바이트까지 전송할 수 있게 된다.

반대 상황은 어떨까?

 

2. 네트워크가 5바이트만큼, 상대의 recv 버퍼가 10바이트만큼 감당할 수 있을 때
=> 네트워크 한계만큼만 전송할 수 있음

똑같이 상대 end-system이 감당할 수 있는 바이트 수는 동일하지만, 네트워크 한계가 감당 가능한 바이트가 버퍼 크기보다 낮아졌으므로 최대 5바이트까지만 보낼 수 있게 된다.

 

네트워크와 recv 버퍼 중 recv 버퍼의 상태가 나쁘다면 recv 버퍼에, 네트워크의 상태가 나쁘다면 네트워크에 전송 속도를 맞추게 된다.

즉, 둘 중 상태가 안 좋은 쪽에 전송 속도를 맞추어야 한다.

 

여기서 recv 버퍼의 상태는 흐름 제어(Flow control)를 통해 이미 알 수 있다. 그러나 흐름 제어는 네트워크의 상태를 알 수 없는데, 혼잡 제어(Congestion control)가 바로 네트워크의 상태를 확인하고 전송 속도를 조절하는 역할을 하게 된다.

 

혼잡 제어가 하는 일

기본적으로 네트워크는 공공의 것(public)으로 소유자가 없다.

누구도 소유하고 있지 않기 때문에 따로 제어하지 않으면 각 기기들은 자유롭게 네트워크를 사용하다가 데이터를 최대한 많이 보내게 된다.

 

그러나 데이터가 너무 많이 보내지면 문제가 발생한다.

라우터에는 한계가 있기 때문에 데이터 전송량이 많아지면 네트워크의 상태가 안 좋아지고 막히게 된다. 데이터 전송이 원활하지 않게 되는 것이다.

 

여기서 문제점은 TCP는 '데이터 전송이 잘 안 되면 재전송을 한다'는 점이다.

지금까지 배운 것에 따르면, TCP는 데이터에 오류가 발생하거나 타임아웃이 발생하면 데이터를 재전송한다. 네트워크 상태가 악화될수록 재전송이 잦아져서 더 많은 데이터를 보내고, 상태를 더 악화시키게 된다. TCP는 상태가 안 좋을수록 상태를 더 악화시킨다. 악순환이 반복되는 것이다.

 

이를 해결하려면 아예 네트워크가 막히지 않게 적당히 조절하는 작업이 필요하다.

네트워크의 소유자는 아무도 없기 때문에 네트워크를 이용하는 각자가 데이터 전송량을 줄이게 된다. 이러한 점에서 TCP는 독립적으로 동작하되 서로 양보해주는 경향을 보인다.

네트워크 상황이 안 좋으면 데이터 전송량을 줄이고, 좋으면 전송량을 늘려준다.

 

이러한 일을 하는 것이 혼잡 제어(Congestion control)이다.

 

혼잡 제어(congestion control)는 전자 통신 네트워크로 들어가는 정보 소통량을 조절하여 네트워크가 혼잡해지지 않게 조절하는 것을 말한다. 예를 들어, 정보 소통량이 과다한 것을 감지하여 패킷을 적게 보내면 혼잡 붕괴 현상이 일어나는 것을 막을 수 있다.

혼잡 붕괴 만들기 - 위키백과, 우리 모두의 백과사전

 

네트워크 상황을 확인하는 방법

그럼 그 네트워크 상황이라는 건 어떻게 알까?

네트워크 상황이 좋은지 나쁜지는 어떻게 알지가 문제가 된다.

단순하게 생각하면 두 가지가 있다.

직접 자세하게 데이터를 보내 주거나, 아니면 간접적으로 네트워크 상황을 유추하는 것이 그것이다.

 

1. Network-assisted congestion control

첫 번째 방법은 네트워크에서 직접 데이터를 보내주는 것이다.

라우터에서 직접 큐 상황 등을 데이터로 보내준다. 그 정보를 통해 각 End-system은 데이터 전송량을 제어한다.

이상적이지만 이 방법은 라우터가 이를 처리하기에 부담이 크다는 문제가 있다.

 

이후 네트워크 계층에서 배우겠지만 라우터는 이미 많은 일을 하고 있기 때문에 이 방법은 어렵다.

 

2. End-end congestion control

직접 자세하게 데이터를 보내주는 것이 안 된다면, 간접적인 정보로 유추하는 방법이 있겠다.

두 번째 방법에서는 클라이언트, 서버 같은 End-system이 네트워크 상황을 유추해서 제어한다.

우리는 ACK 피드백이 돌아오는 데에 걸리는 시간인 RTT(Round trip time)를 알고 있다.

RTT가 예상보다 짧다면 네트워크 상황이 좋은 것이고, RTT가 길거나 아예 유실이 일어나버렸다면 네트워크 상황이 좋지 않은 것이라 볼 수 있다.

 

만약 이렇게 네트워크 상황을 확인했다면 Send 버퍼에서 Window Size를 적당히 정하여 속도를 조절할 수 있다.

 

 

2. TCP Congestion control

3 main phases

TCP에서 흐름 제어(Congestion control)가 구현되는 방법을 알아보자.

 

흐름 제어 과정은 3 main phases로 구성된다.

처음에는 아주 느린 속도로 시작해서 네트워크 병목 현상이 일어날 때까지 계속해서 속도를 올려가는 식으로 전개된다.

 

1. Slow Start: 작은 값부터 시작
   • 병목 현상이 일어나는 대역폭을 알 수 없다.
   • 따라서 아주 작은 값부터 시작해서 전송 속도를 증가시킨다.
   • 다만 증가하는 것은 이름과 달리 전혀 느리지 않다. 1, 2, 4, 8, 16과 같이 지수 배로 증가한다.
   • 여기서 증가하는 숫자는 윈도우 사이즈를 가리킴
2. Additive increase: 천천히 속도를 높임
   • 네트워크에는 임계점(threshold)이 존재해서 그 이상 데이터를 전송할 땐 주의해야 한다.
   • Slow start 과정에서 임계점에 도달하면 Additive increase로 전환
   • 이 과정에서 16, 17, 18, 19와 같은 식으로 천천히 선형적으로 전송량을 늘려간다.
3. Multiplicative decrease: 병목 현상이 발생하면 절반으로 줄인다.
   • 네트워크 상황이 안 좋으면 패킷 유실이 발생
   • 패킷 유실이 발생하면 데이터 전송량을 1/2배로 줄인다.
   • 예를 들어, 패킷 유실이 발생하면 16 → 8
   • 한 번에 전송량을 확 줄이는 이유는, 네트워크가 공유자원이므로 패킷 하나 두 개를 줄이는 것으로는 혼잡(congestion) 상태를 해소하기 어렵기 때문이다.
   • 윈도우 사이즈를 줄인 다음에는 다시 2번 Additive increase 단계로 돌아가서 전송량을 늘린다.

 

흐름 제어(Congestion control)에서 전송하는 데이터량은 MSS를 단위로 한다.

MSS는 max segment size의 약자로 TCP 세그먼트 하나가 가질 수 있는 최대 데이터 크기(Byte)를 가리킨다.

MSS는 IPv4 기준 약 500Byte이다. 한 세그먼트에 500Byte보다 큰 크기는 전송할 수 없다는 말이다. 설정에 따라 MSS는 달라질 수 있다.

 

혼잡 제어(Congestion control)에서는 MSS 단위로 네트워크 전송량을 변화시킨다.

Slow start에서는 무조건 윈도우 사이즈가 1 MSS로 시작하며 1, 2, 4, 8 MSS 순으로 변하게 된다.

 

TCP에서 데이터 전송량은 톱날(Saw tooth) 모양으로 변화한다.

TCP에서는 데이터 전송량이 증가하다가 패킷 유실이 발생하면 Congestion window size가 절반으로 줄어들게 된다.

줄어들고 나면 다시 전송량이 증가하고, 다시 절반으로 줄어들기를 반복해서 톱날 모양으로 속도가 변화한다.

 

네트워크의 임계 지점에서 전송하는 속도만큼 계속 전송하는 것이 가장 좋지만, 임계 지점은 매번 바뀌므로 불가능하다.

 

따라서 파일 전송 시에 전송 속도가 계속해서 변화하게 된다.

 

전송속도

데이터 왕복

패킷이 왕복하는 시간은 RTT(Round trip time)이다.

전송 속도는 단순하게 $rate = \frac{CongWin}{RTT} bytes/sec$로 계산한다.

CongWin은 Congestion Window Size로 전송할 윈도우 사이즈를 가리킨다.

 

RTT는 이용하는 네트워크 회선에 따라 달라지므로 변동이 크지 않다.

반면 전송하게 될 윈도우 사이즈는 계속해서 변화하므로 CongWin의 변동폭은 RTT보다 더 크게 나타난다.

네트워크 상황이 좋으면 CongWin이 증가하고 네트워크 상황이 나쁘면 CongWin은 감소한다.

따라서 네트워크 전송 속도는 CongWin에 의해 좌우된다. 다만 CongWin은 네트워크 상황에 의해 영향을 받긴 하지만 직접적으로 조절하는 것은 개개의 독립된 호스트라는 것이 특징이다.

 

TCP Tahoe vs TCP Reno

TCP Tahoe는 80년대에 등장한 최초의 TCP 혼잡 제어 알고리즘 또는 TCP 혼잡 방지 알고리즘이라 할 수 있다.

Tahoe는 문제점을 내포하고 있어서 그 이후에 TCP Reno가 나오게 되었다. 이후에도 여러 알고리즘들이 등장하였으나, 위 두 개 알고리즘을 통해 혼잡 제어가 어떻게 동작하는지 알아보자.

 

Tahoe와 Reno를 비교한 그래프

TCP Tahoe

위 그림에서 파랑선이 바로 TCP Tahoe의 동작 방식을 가리킨다.

• TCP Tahoe는 Slow start로 시작해서 임계점(threshold)을 넘으면 선형적으로 증가함
• 패킷 유실이 발생하면 Congestion Window size가 무조건 1 MSS로 감소한다.
• 이후 초기 상태로 되돌아와 다시 Slow start부터 시작한다.
• Threshold는 유실이 발생했을 때의 절반이 된다.
• 위의 경우 12 MSS에서 유실이 발생했으므로 Threshold = 12 / 2 = 6 MSS가 된다.

 

Tahoe는 무조건 1 MSS로 다시 되돌아오므로 다시 원상태의 속도로 돌아올 때까지 시간이 많이 걸린다.

이를 개선한 것이 다음 버전인 Reno이다.

 

TCP Reno

Reno는 Tahoe의 다음 버전이다.

Reno를 설명하기 위해서는 패킷이 유실되는 상황이 하나가 아니라는 점을 먼저 알아야 한다.

 

패킷 유실은 두 상황으로 나눌 수 있다.

 

1. 타임아웃 발생
   • 일반적으로 생각할 수 있는 경우.
   • 피드백(ACK)이 돌아오지 않아 타임아웃이 발생하는 케이스
   • 타임아웃이 발생할 정도라면 데이터 전송이 원활하게 이루어지지 않는 환경이므로, 네트워크 상태가 상당히 안 좋은 셈이다.
2. 3 dup ACK
   • 복제된 ACK가 세 번 도달하는 것을 3 duplicate ACK라 한다.
   • 빠른 재전송(Fast retransmit)에 의해 패킷 유실을 감지하는 케이스이다.
   • 해당 패킷만 문제가 있고 네트워크 상태는 정상이다.

 

기본적으로 타임아웃이 발생할 때가 3 dup ACK보다 네트워크 상황이 나쁘다.

네트워크 상황이 나쁘지 않다면 데이터 전송량을 1 MSS까지 감소시킬 이유가 있겠는가?

두 번째 TCP 버전인 Reno는 이 점을 고려한다.

 

위 그림에서는 파랑선과 검정선이 TCP Reno의 동작 방식을 가리킨다.

TCP Reno는 아래에 기술된 바에 따라 행동한다.

 

•  패킷 유실 판별 조건에 따라 다르게 행동
• 3 dup ACK → 네트워크 상황이 좋으므로 Congestion Window size를 현재의 절반으로 내린다.
• Timeout → 기존과 동일하게 Congestion Window size를 1 MSS로 내린다.

 

Threshold는 Tahoe와 동일하게 (Congestion Window size / 2)로 정한다.

 

초기 Threshold 값

사실 여기서 하나 문제가 있는데, 바로 Threshold 값이다.

네트워크 상황은 라우터를 하나하나 확인하지 않는 한 정확하게 알 수 없다. 특히 패킷을 보내보기 전까지는 임계점(Threshold)은 예측하기 어렵다.

 

그래서 초기 Threshold 값은 따로 정하는 방법이 없다고 한다.

구글에 검색해보니 4KB 정도로 정하는 것으로 보인다.

latency_size_web_expid40-41.eps (googleusercontent.com)

 

TCP Reno 정리

• 패킷 유실이 timeout에 의한 것인지 3 dup ACK에 의한 것인지에 따라 동작 방식이 달라진다.
  • 타임아웃은 Threshold = CongWin / 2로 하고, CongWin = 1 MSS로 정한다.
  • 3 dup ACK(triple duplicate ACK)의 경우 Threshold는 동일하고 CongWin = Threshold 값으로 설정한다.
• 초기를 제외한 Threshold 값은 직전에 패킷 유실이 발생한 window size의 절반으로 정한다.

 

 

 

참고 자료

MSS (ktword.co.kr)

MSS

전송 제어 프로토콜 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

전송 제어 프로토콜 - 위키백과, 우리 모두의 백과사전

TCP 혼잡 방지 알고리즘 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

TCP 혼잡 방지 알고리즘 - 위키백과, 우리 모두의 백과사전

TCP congestion control - Wikipedia

TCP congestion control - Wikipedia