[Network] TCP (2) : TCP Flow Control, Congestion Control (흐름 제어와 혼잡 제어)

TCP : Connection 및 Error Control

 

TCP Flow Control과 Error Control에 대해 살펴보기 앞서, TCP의 기본 개념과, 패킷, Error Control에서의 Window Size에 대해서 잘 모른다면 해당 글을 먼저 참고하고 오면 좋을 것 같다.

 

https://sjh9708.tistory.com/193

[Network] TCP (1) : Connection과 Handshake, 그리고 TCP Error Control

 

---

TCP Flow Control (흐름 제어)

TCP에서 데이터의 흐름을 조절하여 Receiver가 처리할 수 있는 속도로 데이터를 전송하는 메커니즘

네트워크의 혼잡을 방지하고 안정적인 데이터 전송을 보장하기 위해 사용된다.

즉 Sender가 Receiver의 버퍼가 Overflow 되는 것을 방지하기 위해 보내는 패킷 양을 조절하는 것으로 Reciever가 버벅거리면 Window Size를 작게 해주어야 한다.

• Overflow : Application layer가 Buffer의 데이터를 다 읽기도 전에 엄청 많은 데이터가 들어와서 결국 데이터는 폐기된다.

 

Window 크기 제어

흐름 제어의 기본적인 아이디어는 Window 크기의 제어이다. Sender와 Receiver은 각각 Window를 가지고 있다고 이전 포스팅에서 언급하였다. 또한 Clinent도, Server도 Sender이면서 Receiver이다. 따라서 둘 다 Sender window와 Receiver window가 있다.

윈도우는 수신자가 받을 수 있는 데이터의 양이며, 송신자는 수신자의 윈도우 크기를 고려하여 데이터를 전송한다. 따라서 수신자의 처리 속도에 맞게 데이터를 보낸다.
송신자와 수신자 간의 윈도우 크기를 동적으로 조절하여 최적의 전송 속도를 유지하려고 한다. 이를 통해 수신자가 처리할 수 있는 속도를 초과하지 않도록 조절한다.

 

 

1. rwnd : Receiver가 size를 결정해야 한다. 이 사이즈로 정해진 Window size

2. Buffered data : 데이터가 차서 사용 불가한 부분. sender가 보내서 저장해 놨는데 application이 아직 읽지 않은 부분

3. Free buffer space : 사용 가능한 공간 –> rwnd로 set한다. 이것을 Tcp header에 적어서 보낸다.

 

 

 

Receiver가 Sender에게 Size를 알려주는 방법 : Segment 보면 Window size가 있다. 이것이 자신이 가용가능한 Size를 알려주는 역할을 한다.

Flow control에서의 Window control : Receiver가 Sender에게 자신이 가용한 버퍼의 크기를 알려주는 것. 버퍼의 크기를 고려해서 Sender Window Size 결정.

Flow control을 위한 Window size : TCP 헤더에 있는 Window size 필드에 적어서 Receiver가 Sender에게 알려준다.

Reciever가 자신의 가용 가능한 버퍼량을 계산하는 방법 : 운영체제가 해당 TCP 세션에 대해 할당해 놓은 가상의 버퍼를 상황에 따라서 결정.

 

 

---

TCP Congestion 

 

Congestion : 너무 많은 소스 들이 너무 많은 데이터를 네트워크가 처리하기 어려울 정도로 더 빨리 보내는 상황. 네트워크의 혼잡은 주로 Queueing deley에 의해 일어난다. 즉 여러 개의 Input port에서 들어온 데이터가 하나의 Output port로 몰려 Delay 발생하는 상황을 들 수 있다.

Congestion의 영향 : 패킷 Loss, Delay

 

 

두개의 포트가 있다. 왼쪽 1번 포트 오른쪽 2번 포트 1번 포트의 A와 B 두개의 소스에서 데이터가 들어와서 2번 포트로 나가는데 두개의 TCP 세션이 하나는 C로가고 하나는 D로가는 경우이다.

 

1. 버퍼가 무한대인 상황. Congestion이 발생해도 lost packet이 없다.

 

2. 이번에는 UDP를 사용하면서, A와 B의 Transmission rate가 동일하다고 가정

1번과 2번 포트 모두 Link capacity가 R이라고 하자. R/2까지는 문제없이 가고 R/2를 넘어가면 그 이상으로는 전송을 못 한다 왜냐하면 2번 포트의 Link capacity가 R이기 때문에 넘어가면 Segment가 무한대로 쌓이기 시작한다. 그래서 Delay는 무한대가 된다.

 

해결방법은 A와 B가 보내는 Data양을 R/2이하로 조절하는 것. 그것이 TCP가 하는 역할이다.

평균 Transmission Rate가 R/2에 근접하면 delay는 기하급수적으로 커진다. R/2에 도달하면 무한대가 된다(쌓인 데이터의 양 = Delay)

따라서 쌓인 Data의 양으로 Input rate를 결정한다.

 

 

 

 

이 경우에는 버퍼가 유한한 경우를 상정해보자.

패킷 Loss가 발생하고,TCP 세션으로 Retransmission을 한다.

UDP와 다르게 Delay가 무한대로 늘어나진 않지만 Loss가 발생하고 더 큰 Data Rate로 TCP가 보낸다(Retransmission 때문) 

 

 

 

 

이번에는 라우터 두개를 건너가는 상황이다.

R1이 버퍼가 꽉꽉 차면 패킷이 들어오고 Host D에도 영향 받아서 Retransmission을 계속 요청. R4, R3, R2도 차례로 Congestion이 발생하고 전체적으로 망가지게 된다.

즉, Congestion이 발생하면 하나가 망가지면 다 망가진다. 그래서 TCP는 매우 보수적인 방법으로 Congestion을 제어한다.

 

 

Throughput

 

Sender에서 Receiver까지 전달되는 Data양을 Time으로 나눈 것.

실제 전송률. Input data rate가 작을 때는 같이 따라 올라가지만 어느 정도 되면 같이 망가지고 더 가면 0에 수렴하게 된다.(해당 경우에는 아무 데이터도 통과하지 못하는 상황이 된다.)

 

 

 

 

 

---

TCP Congestion Control (혼잡 제어)

 

네트워크의 혼잡을 방지하고 네트워크의 성능을 최적화하기 위해 TCP에서 사용되는 메커니즘

 

 

Congestion Control : 혼잡 상황을 감지하고 혼잡 상황일 경우 Window 사이즈를 줄여준다. Sender가 네트워크 혼잡 감지를 하면 조금만 데이터를 보낸다.

 

TCP의 Congestion 감지 방법 : Packet loss가 발생하면 Network가 혼잡 상태라고 유추한다. 즉 ACK가 안오면 혼잡이라고 가정한다. 

 

Window Size 조절 : Windows size는 min(cwnd,rwnd)의 수치만큼 줄이게 된다.

• cwnd : Congestion window size. 이것을 얼마로 할 것인가?
• cwnd 조절 방식 :
  • 1000이니가 ACK가 잘 안오는 경우 : 1000->100
  • 100으로 줄이니 ACK가 잘 오는 경우 : 그러면 조금씩 늘린다. 100->120->500->2000->4000
  • 4000까지 늘리니 ACK가 잘 오지 않는 경우 : 그러면 또 확 줄인다, 4000 -> 400.. Packet이 loss되는 시점에 줄인다. 

 

Congestion Control의 기본 원리

Short-term : 잠깐, 우연히 발생하는 Congestion (ex : Text 기반의 웹브라우징. Internet의 트래픽은 잠깐 나타났다 사라지는 트래픽)

-> 버퍼를 충분히 확보함으로서 어느정도 해결 가능

Long-term : 데이터 Congestion가 오랫동안 지속이 되는 경우.

-> 이 경우에는 Sender가 Transmission rate를 줄이는 것이 해결책(즉, Window size를 줄인다) 

• Transmission rate : 전송률을 뜻한다. Segment의 수 * Segment의 크기 / 시간

 

 

 

---

Congestion Control 방식

 

1. 중간의 라우터 도움 없이 Sender와 Receiver의 Handshake만으로 Congestion 제어.

간단하다는 장점. 네트워크의 의존성 X. Sender와 reciver간의 정보교류만으로 제어. 해당 방식이 TCP의 기본 원리이다.

 

2. 네트워크의 중계노드(라우터)의 도움

라우터가 버퍼가 꽉 찼다는 정보를 전달해준다. 해당 방식은 ECN이라는 Field를 만들어두고 1bit짜리 1이면 포화, 0이면 원활하다고 알리는 방식이다. 또한 혼잡 상태이니 해당 속도 이상으로 보내지마 라고도 Signal을 보내는 방식도 있다.

해당 방법은 좋은데 우리가 사용하는 인터넷에서는 사용하지 않는다. 왜냐하면 이미 TCP가 자리를 잡고 잇기 때문이다. 이미 자리잡은 표준 기술을 대체하기는 힘들다.

 

TCP Congestion Control 문제점 : Congestion만으로 Packet Loss가 발생하는 것이 아니라는 문제점. 무선 인터넷에서 옆 사람과의 충돌 등 다른 상황에서도 발생할 수 있다.

 

 

 

Original Concept : TCP

 

1. 초기 Window size 조절 : Additive increase & Multiplicative decrease (가산 증가, 곱셈 감소)

별일 없으면 (ACK 가오면)가 평이하게 올라간다(하나의 Segment size만큼).

Packet Loss가 발생하면 그다음에 Window size를 반으로 줄인다. 그리고 Loss가 발생할 때 까지 또 additive하게 증가한다.

이게 너무 시간이 오래 걸리고, 보수적이라는 의견이 나왔다. 그래서..

 

2. Window size 조절 : Slow Start

그 후에 여러 가지 제안 중 채택된 것. 초기에는 전송 속도를 느리게 시작하여 네트워크의 상태를 파악하다가, 마찬가지로 Packet Loss가 발생하면 Window Size를 줄인다. 그 이후 Additive increase가 너무 시간이 많이 걸리니 Window size를 두 배씩, 즉 기하급수적으로 증가시킨다. 이 메커니즘을 Slow start라고 부른다. 이름과 메커니즘이 이질감이 드는 단어이다.

 

 

 

 

TCP Tahoe & TCP Reno

 

https://commons.wikimedia.org/wiki/File:CongWin_in_TCP_Tahoe_e_Reno.png

TCP Tahoe

초기의 TCP 구현 중 하나로, 혼잡 제어 및 회복 메커니즘의 한 형태이다. Tahoe는 혼잡이 발생하면 윈도우 크기를 줄이고, Slow Start를 수행하여 전송 속도를 조절한다.

 

1. Congestion 감지 시(Timeout 혹은 3-duplicate ACK) 현재 윈도우 값의 ½를 threshold로 저장한 후. Window Size를 1로 줄인다.

2. 그다음 Slow start(Exponential increase)를 Threshold까지 진행한다.

3. Congestion Avoidance : 그리고 나서 Window Size를 Addictive increase

 

 

TCP Reno

Tahoe에서 발전된 형태로서 Slow Start기능을 포함하면서도, Fast Recovery 기능을 추가하여 더욱 효율적으로 혼잡을 제어한다.

 

Fast Recovery : 3-Duplicate ACK 발생(Tcp가 201번 패킷을 받은 후, 401번 501번 601번 받는 경우)

세개만 Loss 됫다고 가정하여  Congestion이 그렇게 심각하지 않다 라고 생각 할 수 있다. 이 경우에는 ½로 줄이고 Addictive하게 Window Size를 증가시킨다.

cf) Timeout 발생 : Window size를 1로 줄인다.

 

 

 

 

---

TCP 제어 비교 및 정리

 

Congestion Control

• 네트워크의 혼잡을 방지하고 안정적인 데이터 전송을 보장하기 위해 사용
• TCP의 송신자가 네트워크 상황을 모니터링하고 데이터 전송 속도를 조절하는 메커니즘. Slow Start, Congestion Avoidance, Fast Recovery 등의 로직으로 동작.

 

Flow Control

• 수신자가 처리할 수 있는 속도로 데이터를 전송하여 수신자의 버퍼 오버플로우를 방지
• 수신자가 송신자에게 자신의 버퍼 상태를 알리고, 송신자는 이를 기반으로 데이터 전송 속도를 조절
• 수신자의 버퍼의 상태는 Window Size를 통해 알 수 있다.

 

Error Control

• 데이터의 손실을 탐지하고 복구
• 수신자가 송신자에게 데이터의 수신 여부를 확인하고, 송신자는 수신자로부터 ACK를 받아 데이터의 손실이나 손상을 탐지, 오류가 발생하면 송신자는 손상된 데이터를 다시 전송(Retransmission)하여 오류를 복구한다. 3-Duplicate ACK로 주로 손상 신호를 보낸다.

 

 

---

Wireshark로 본 Congestion Control

 

 

1. Sequence number가 급격하게 감소하였다가 증가하는 구간 :TCP segment의  Retransmission이 이루어 짐

2. Window Size 12000 -> 6000 : Fast Recovery 후 Addictive하게 Window Size를 증가.

 

 

 

---

References

 

Data Communications and Networks, 4th Edition, Forouzan, McGraw-Hill

Computer Networking: A Top-down Approach, 6th Edition, Kurose and Ross, 2013