[인터넷 공학] 흐름제어(Flow Control)와 TCP혼잡제어 (Congestion Control)

흐름제어(Flow Control) 란?

 

• 더 빠른 송신자가 느린 수신자를 제압하지 못하도록 두 노드 간 데이터 전송 속도를 관리하는 과정이다.
• 수신 노드가 전송 노드의 데이터에 제압되지 않도록 수신자가 전송 속도를 제어할 수 있는 메커니즘.
• 각 데이터 처리 속도가 송신(보내는) > 수신(받는) 일 경우 data loss(패킷 손실) 발생 -> 큐잉 지연

 

★흐름 제어는 혼잡이 실제로 발생할 때 데이터의 흐름을 통제하기 위해 사용되는 혼잡제어와는 구별된다.

 

 

흐름제어 방법의 종류(1)

흐름제어 종류 1)  "Stop and Wait"

• 매번 송신자는 자신이 보낸 패킷에 대한 확인 응답(ACK)을 받아야 그다음 패킷을 전송할 수 있다. (응답 전까지 대기, 시간소모 UP)
• Give & Take 방식이고 비효율적이다.
• 요즘 네트워크에서 사용되지 않는 방식이다

흐름제어 종류 2) "Window Slicing"

수신 측(ex. 라우터 등)에서 설정한 윈도우 크기만큼 송신에서 확인응답(ACK) 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 기법

흐름제어 - window slicing - 1

• Stop and Wait의 비효율성을 개선한 기법 
• 송신 측에서 1, 2, 3, 4, 5, 6을 보낼 수 있는 프레임을 가지고 있고 데이터 1,2를 전송했다고 가정하면 슬라이딩 윈도우 구조는 3, 4, 5, 6, 7으로 변하게 된다. 
• 만약 수신 측으로부터 ACK라는 프레임을 받게 된다면 송신 측은 이전에 보낸 데이터 1, 2를 수신 측에서 정상적으로 받았음을 알게 되고 송신 측의 슬라이딩 윈도우는 ACK 프레임에 따른 프레임의 수만큼 오른쪽으로 경계가 확장된다. 

동적으로 변하는 것에 대해 3가지 구분으로 설명이 가능하다.

window slicing 구분/설명

---

혼잡제어 (Congestion Control)이란?

• 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도를 해결하기 위한 기법
• 한 라우터(송신 측)에게 데이터가 몰려 모든 데이터를 처리할 수 없는 네트워크 혼잡 현상이 발생한 경우, 호스트들은 재전송을 하게 되고 결국 혼잡만 가중시켜 오버플로우나 지연으로 인한 데이터 손실이 발생한다 ★네트워크의 혼잡을 피하기 위해 송신 측에서 보내는 데이터의 전송 속도를 제어하는 것이 혼잡 제어의 개념이다.

 

혼잡제어 종류 1) "  AIMD (Addtive Increase Multicative Decrease)"

• 합 증가 / 곱 감소 알고리즘
• 처음(round 1)에 패킷 하나를 보내는 것으로 시작하고, 전송한 패킷이 문제없이 도착한다면 Window Size를 1씩 선형으로 증가시키며  Next round에 전송한다.
• 패킷 전송을 실패하거나 타임아웃이 발생하면 Window Size를 절반으로 감소시킨다. 
• 문제점은 초기 네트워크의 높은 대역폭을 사용하지 못하고 네트워크가 혼잡해지는 상황을 미리 감지하지 못하여 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

"여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형 상태로 수렴하게 되는 특징" 

window size를 1 MSS씩 증가시키기 때문에 네트워크의 모든 대역을 활용하여 빠른 속도로 통신하기 오래 걸린다

 

 

혼잡제어 종류 2) "Slow Start"

• AIMD에서 네트워크의 수용량은 효율적으로 동작하지만, 처음에 전송 속도를 올리는 데 시간이 너무 길다는 한계점을 보완
• Slow Start는 AIMD와 마찬가지로 패킷을 하나씩 보내는 것은 동일.
• Slow Start는 첫 번째 패킷이 문제없이 도착한다면. 다음 라운드에서는 2^n (n>1로 n값이 순차적으로 증가) 개의 패킷을 전송  
• 그래프의 모양은 지수 함수 꼴이 된다  (2의 n제곱 그래프)
• 패킷 손실이 발생하면 Window Size를 1로 무조건 떨어뜨린다 
• 처음에는 네트워크의 수용량을 예측할 수 있는 정보가 없지만 한번 혼잡 현상(3개의 중복 ACK, 타임아웃)이 발생하면 네트워크 수용량을 어느 정도 예측할 수 있으므로 혼잡 현상이 발생하였던 Window Size의 절반을 임계점으로 설정하고 임계점까지는 이전처럼 지수 함수 꼴로 Window Size를 증가, 그 이후부터는 완만하게 1씩 증가시키는 방식.

혼잡제어 알고리즘 (TCP Tahoe)

임계값을 알고 있는 TCP Tahoe

TCP Tahoe는 Slow-Start + 혼잡 회피로 구현된 방식

1. TCP를 연결한다
2. window size는 1에서 시작 (Slow start)
3. window size 지수적으로 증가 (Slow start)
4. loss 발생 시, 현재 window size의 절반을 ssthresh 값으로 설정 후 window size는 1에서 다시 시작.
5. ssthresh 값에 다시 도달하면, window size는 1씩 증가. (AIMD)

위 그래프는 임계점을 인지하고 시작하였지만 대체로 아래의 자료처럼 처음은 임계값을 모르고 스타트하기에 손실까지 지수승으로 증가

임계값을 모를 경우

 

TCP Tahoe의 특징

★ 중복이나 타임아웃 발생시 window size가 1부터 다시 시작하기 때문에 속도가 느리다

 

혼잡제어 알고리즘 (TCP Reno)

TCP Reno는 TCP Tahoe와 비슷하지만 3개의 중복 ACK와 timeout을 구분한다는 점이 다르다.

• 임계점까지 슬로 스타트 (지수승 증가)
• 임계점부터 AIMD 방식 사용
• 3개의 중복이 되면 window size 절반 = 임계점 값 수정
• Timeout 발생 시 window size만 1로 줄인다

혼잡제어 알고리즘 (TCP new Reno) (1999)

네트워크에서 패킷 손실은 연속적으로 일어나는 경향이 매우 강하다.

 

연속적인 손실(중복 ack)이 발생하면 window size를 계속해서 절반으로 줄이는 사태가 발생할 수 있다.

예를 들어 손실이 3번 연속으로 발생하면 window size는 기존 size의 1/8이 되어버리는 문제가 발생하게 된다.

 

위 문제를 해결하기 위해서 TCP Reno의 빠른 회복 방식을 개선한 방식이 TCP NewReno이다.

 

1. 패킷 loss(중복 ACK)를 감지한다.

2. fast recovery 상태에 들어간다.(window size는 절반이 됨)

3. 지금까지 보냈던 패킷들에 대한 ACK가 모두 도착할 때까지 fast recovery상태를 종료하지 않는다.

4. 마지막에 보냈던 패킷에 대한 ACK가 오기 전에 패킷 loss가 한번 더 감지된다.

5. window size는 절반이 되지 않고 현재의 fast recovery 상태를 유지한다.