[컴퓨터 네트워크] - Transport layer_TCP Congestion control

지난 글에서는, TCP의 연결 방식인 3-way handshaking과 TCP의 연결 종료까지 정리해 보았다. 이번 글부터는 TCP의 주요 기능 중 하나인 Congestion control, 즉 혼잡 제어에 대해서 정리해 보려고 한다.

---

1. Principles of Congestion control

 먼저, congestion control의 기본적인 원칙들부터 알아보자.

 

 Congestion은 network가 다룰 수 없을 만큼의 많은 source들이 빠르게 보내질 때 생긴다. 예를 들면, 명절 연휴 때, 고속도로에 몰리는 차들을 생각하면 된다. 

 

 이런 Congestion이 생길 때, network에서는 다음과 같은 일이 발생한다.

• long delays : router buffer의 큐에서 발생하는 delay
• packet loss : buffer에 결국 데이터가 다 차서 overflow 상황이 발생해 packet loss가 생긴다.

 지지난 글에서 다뤘던 flow control과는 다르다. Flow control에 대해서 간단히 복습하면, receiver 측 buffer의 용량 상태를 고려해 segment의 recevier window field를 통해 sedner의 전송 양을 조절하는 것이다.

 

 즉, flow control과 congestion control을 간단히 비교해 보면, 

• flow control은 한 명의 sender가 한 명의 receiver에게 너무 많은 양의 데이터를 보낼 때,
• congestion control은 너무 많은 sender가 너무 빨리 보낼 때, network에서 발생하는 것이다.

---

2. Approaches toward congestion control

 Flow control은 지지난 글에서 해결책이 존재했다. Receiver window field를 통해 현재 buffer의 상태를 sender에게 알려주어 sender가 보내는 데이터 양을 조절하게 했다.

 

 그렇지만, congestion control은 flow control과 같이 1 대 1 상황에서 발생하는 것이 아닌 다수의 sender가 데이터를 빠르게 보내는 것이기 때문에 flow control과 같은 segment structure의 field로 조절할 수 없다.

 

 즉, congestion control은 flow control과 같이 즉각적인 피드백을 통해 제어할 수 없다. 직접 관찰된 loss, delay를 통해 제어하게 되는데, 이것이 TCP에 구현되어 있다. 

 

 간단한 아이디어는 라우터가 데이터를 주고받는 sending/receiving host들에게 직접 피드백을 주는 것이다. 다음 그림을 살펴보자.

 위 그림은, client와 server가 data와 ACK들을 주고받고 있는 상황이다. 이때,

• 가운데 router에서 혼잡도가 높아진다면,
• 이 router를 통해 데이터를 주고 받는 host들에게 혼잡도가 높아졌음을 직접 알린다.

위와 같이 router를 이용해 혼잡도를 알리는 방식은 TCP의 확장인 TCP ECN에서 라우터가 ECN bit를 세팅하고 알리는 방법이다. 그렇지만, 이는 기본 TCP에는 포함되지 않는다.

 

 TCP의 congestion control은 기본적으로 라우터의 직접적인 피드백 없이, sender가 ACK의 지연이나 패킷 손실을 통해 네트워크 혼잡을 간접적으로 감지하고 대응한다.

---

3. AIMD(Additive Increase Multiplicative Decrease)

 그렇다면 기본 TCP congestion control 방식에는 뭐가 있는지 알아보자. AIMD 방법을 사용해 congestion control을 구현하기도 한다.

 

 AIMD는 생각보다 간단하다.

1. sender는 packet loss가 발생하기 직전까지(congestion이 일어나기 전까지) 전송 속도를 올리고,
2. loss가 발생하면 전송 속도를 낮추는 방식이다.

다음 그래프를 확인해 보자.

 

 위 그래프는 시간에 따른 TCP sender의 전송 속도를 나타낸 것처럼 보이지만, 실제로는 Congestion Window (cwnd)의 변화를 나타낸 것이다. cwnd는 sender가 한 번에 전송할 수 있는 데이터 양을 의미하며, 이는 전송 속도와 비례 관계에 있기 때문에 전송 속도 그래프처럼 해석할 수 있다.

 

 이 그래프에서는,

• 매 RTT마다 1MSS(maximum segment size)씩 보내는 양을 올리며(속도도 비례해 증가) segment를 보낸다.
• packet loss가 detect되면, 매 loss 사건 마다 전송 속도를 반으로 줄인다.

 여기서 생기는 궁금증은 보통 보내는 양이 많아지면 처리 속도가 느려질 것이라고 예측한다. 하지만 TCP에서는, 적어도 네트워크 관점에서, 보내는 양(cwnd)을 늘리면 전송 속도도 함께 증가한다.

 즉, 네트워크가 허용하는 범위 내에서는, 보내려는 양이 많아질수록 전송 속도도 같이 증가한다. 그러나 혼잡이 감지되면, TCP는 이를 신호로 받아들여 전송 속도를 곧바로 절반으로 줄인다.

 

+) 위 그래프는 톱니처럼 생겼다고 해 AIMD sawtooth라고 불리기도 한다.

 

  AIMD는 MSS가 Multiplicative(곱셈적)하게 감소해 Multiplicative decrease라고 부른다. 이때, 2가지 방법이 존재하는데, 

1.  3번의 중복 ACK를 받는다면, sender는 fast retransmission을 진행시키는데, 이때, 네트워크는 3번의 중복 ACK를 받은 상태이므로 혼잡한 상황이 아니지만, 원래의 속도의 절반만큼으로 보낸다. 
2. timeout이 발생하면, sender는 retransmission을 진행시키는데, 이때, 보내는 데이터의 양을 1MSS까지로 떨어뜨려 보낸다. 

 또, AIMD는 TCP를 사용하는 모든 hosts에 공통적으로 적용되는 congestion control 알고리즘이다. 그렇지만, 이 알고리즘은 각 host가 알아서 계산을 진행하기 때문에, 모든 host의 cwnd가 동일하게 움직이지 않고, 동일한 시점에 packet loss를 감지하지 않는다.

 

 즉, 전역적으로 구현된 알고리즘이지만, 비동기적(asynchronous) 알고리즘이라고 부른다. 이러한 특성 때문에 분산(distributed) 알고리즘이라고도 불린다.

 

---

 

 다음 그림을 보며 조금  더 자세히 알아보자.

 

sender 측의 window를 나타낸 것이다. cwnd는 TCP sender가 네트워크에 보낼 수 있는 데이터의 최대 양(MSS 단위)을 나타내며, 다음과 같이 구성된다 .

• 초록색 : ACK까지 받은 상태의 데이터
• 노란색 : 보냈지만, ACK는 아직 받지 않은 상태의 데이터
• 파란색 : 아직 전송하지 않은 상태지만, 보낼 수 있는 여유 공간(cwnd에 포함)

이때, TCP sender는 전송 속도를 다음과 같이 제한한다.

LastByteSent - LastByteAcked <= cwnd

즉, 노란색에 해당하는 부분이 cwnd보다 작거나 같을때까지만 MSS를 증가시키며 속도도 같이 증가시킨다. 이렇게 되면, cwnd는 자연스럽게 network의 혼잡도에 따라 dynamic하게 바뀌는 값이 된다.

 

이때, TCP rate와 cwnd의 관계식은 다음과 같이 정의된다.

TCP rate  ≈ cwnd/RTT

즉, cwnd가 크면 클수록, RTT가 작으면 작을수록 TCP rate는 빨라진다.

---

4. TCP slow start

 이번에는 TCP의 congestion control 방식 중 하나인 TCP slow start에 대해서 정리해 보려고 한다. TCP slow start는 다음과 같은 아이디어로 고안되었다.

• 처음 cwnd = 1 MSS로 시작한다.
• 그 후, 매 RTT마다 cwnd를 2배씩 증가시킨다.

이렇게 되면 처음의 속도는 느리지만, 지수적으로 속도가 증가하게 된다. 다음 그림을 한 번 살펴보자.

위 그림에 대해서 설명해보면,

1. 처음에 하나의 세그먼트로 시작한다(cwnd크기=1 MSS).
2. 해당 ACK를 받고 cwnd 크기를 2배로 늘려준 뒤, 2개의 segment를 전송한다.
3. ACK가 들어오면 다시 cwnd 크기를 직전의 2배로 늘려준 뒤 segment를 전송한다. 즉, cwnd = 4 MSS가 되고, 총 4개의 segment를 전송한다.

이런 방식으로 매 RTT마다 cwnd가 2배씩 증가하며, 처음에는 느리게 시작하지만 시간이 지날수록 전송 가능량이 지수적으로 증가한다.

 

 

그럼, 이런 방법은 congestion을 피하기 위해 어떻게 해야될까? 즉, TCP slow start는 속도가 지수적으로 증가하는데, 언제까지 증가할 수 있을까?

---

5. Congestion Avoidance

 위의 질문에 대한 해답이 바로 congestion avoidance이다. 다음 그래프를 살펴보자.

 

 

위 그래프에 대해서 설명하면,(가로축 Transmission round = RTT, 세로축 Congestion window = cwnd를 나타냄)

• RTT가 1일 때부터 4일때까지 cwnd가 지수적으로 증가함을 볼 수 있다. 즉, 1~4까지는 TCP slow start를 이용해 데이터를 전송한 것이다.
• 그런데, cwnd가 특정 시점인 8(=ssthresh)에 도달했을 때, 즉, 문제를 일으키는 시기가 다가오니, 증가하는 기울기가 달라졌다. (ssthresh = slow start thresh hold)
• 기울기가 달라진 시점부터, 즉, cwnd 증가가 느려진 이후부터를 congestion avoidance 단계라고 한다. 
• 이렇게 천천히 증가하다가 X 부분에서 timeout이 발생하고,
• 이렇게 되면, ssthresh가 현재 cwnd의 절반으로 줄게 된다. 즉, 12였던 cwnd에 맞춰 ssthresh는 절반인 6이 된다.
• 그리고 다시 1 MSS부터 전송을 시작한다. 
• 이때, X 지점에서 timeout이 아닌 3번의 중복 ACK를 받는다면, TCP Reno처럼 MSS를 6으로만 줄여서 보낸다.(네트워크가 혼잡한 상태가 아니기 때문에)

이렇게 TCP slow start와 Congestion avoidance를 동시에 활용해 congestion control을 구현하는 경우도 있다.

---

6. Congestion Control 정리

 

위 그림을 한 번 살펴보자.

 

- Slow Start

1. 초기값
   1. cwnd = 1 MSS
   2. ssthresh = 64 KB
   3. dupACKcount = 0
2. 새로운 ACK를 받았을 때
   1. cwnd = cwnd + MSS(cwnd는 지수적으로 증가)
   2. dupACKcount = 0으로 초기화
3. timeout 발생 시
   1. ssthresh를 현재 cwnd의 절반으로 줄인다.
   2. cwnd = 1 MSS부터 다시 전송한다
   3. duplicated ACK이 발생한 상황은 아니기 때문에 dupACKcount = 0으로 초기화 시킨다.
4. duplicated ACK 발생 시
   1. duplACKcount값을 증가시킨다.
5. dupACKcount = 3일 때
   1. ssthresh를 현재 cwnd의 절반으로 줄인다.
   2. cwnd = ssthresh + 3 (3개의 중복 ACK에 대한 보상)
   3. fast recovery로 상태 변화
6. cwnd >= ssthresh일 때
   1. slow start에서 cogestion avoidance로 상태 변화

 

- Congestion Avoidance

1. 새로운 ACK를 받았을 때
   1. cwnd = cwnd + MSS * (MSS/cwnd) (cwnd를 선형적으로 증가시키기 위해서)
   2. dupACKcount = 0으로 초기화
2. timout 발생시
   1. sshthresh를 현재 cwnd의 절반으로 줄이고,
   2. cwnd = 1 MSS, dupACKcount = 0으로 초기화 시킨다.
   3. 그 뒤, 다시 slow start로 상태 변화
3. duplicated ACK 발생 시
   1. dupACKcount값을 증가시킨다.
4. 3개의 중복 ACK 발생 시 
   1. sshthresh를 현재 cwnd의 절반으로 줄이고,
   2. cwnd = ssthresh + 3
   3. fast recovery 상태로 변화

- Fast Recovery

1. 여전히 duplicated ACK가 들어오는 경우
   1. cwnd = cwnd + MSS(ACK가 들어온다는 것은 네트워크 상황이 괜찮다는 것이고, cwnd를 감소시킬 필요는 없다.)
2. 새로운 ACK를 받았을 때
   1. cwnd = ssthresh, dupACKcount = 0으로 초기화
   2. Congestion Avoidance로 상태 변화
3. Timeout이 발생했을 때
   1. duplicated ACK이 3번 발생하고 timeout이 발생하면, 네트워크가 혼잡하다고 판단
   2. ssthresh = cwnd / 2
   3. cwnd = 1 MSS, dupACKcount = 0으로 초기화
   4. Slow start로 상태 변화

---

7. TCP CUBIC

  AIMD(Additive Increase Multiplicative Decrease)는 TCP Reno 등에서 사용되며, 혼잡이 없을 때 선형적으로 증가하고, 혼잡이 발생하면 곱셈적으로 감소(multiplicative decrease)한다.

 

 이때, 그래프 모양은 일정하지 않고 톱니형으로 나타나게 됐고, 일정한 bandwidth(대역폭)를 안정적으로 유지하거나 측정하기 어려워진다. 이러한 방식은 대역폭을 최대한으로 활용하지 못하는 단점이 있다.

 

 이를 보완한 것으로 나타난 방법이 TCP CUBIC 방법이다. CUBIC은 말 그대로, 3차를 나타내는데,  TCP CUBIC에 대한 아이디어는 다음과 같다.

• Wmax : congesion loss가 관측되는 sending rate
• 혼잡이 발생하는 bottleneck link는 아마 혼잡 상태가 크게 변하지 않을 것이다.
• Wmax/2까지 속도/cwnd를 낮추고, Wmax까지 엄청나게 빠르게 증가시킨다. 이때, Wmax에 가까워질 수록 천천히 증가하게 만든다.

위와 같은 아이디어를 이용해 나타난 그래프는 다음과 같다.

 

위 그래프에 대해 설명하면,

• 빨간색 선은 classic TCP의 증가 형태를 나타낸 것이다.
• Wmax는 혼잡이 발생하는 시점에서의 보내는 속도를 나타낸다.
• classic TCP는 congestion avoidance단계에서 Wmax에 가까워 질 때 선형적으로 증가한다.
• TCP CUBIC은 점선과 같은 그래프의 형태로, Wmax까지 빠르게 속도가 증가하다가 Wmax에 가까워질 수록 증가율이 낮아진다. 이때 모양은 3차함수의 모양과 비슷하다.
• Wmax에 도달하면 class TCP와 TCP CUBIC 모두 cwnd를 절반으로 감소시킨다.

이렇게 되면, classic TCP에 비해 TCP CUBIC은 혼잡 이후 Wmax까지 더 빠르게 회복하고, 그 이상으로도 적극적으로 전송 속도를 증가시킨다. 즉, 가용한 bandwidth를 더 효율적으로 활용할 수 있게 된다.

 

TCP CUBIC에 대해서 설명을 덧붙이자면, 다음을 가정해보자.

• K : TCP window 사이즈가 Wmax의 도달했을 때의 시점(사용자나 OS에 의해 조정가능하다.)
• 현재 시점을 ti라고 가정
• 이때, W를 (ti-K)^3만큼씩 증가시킨다.

위 상황과 3차 함수의 특징을 고려하면, t가 K에 가까워질수록, 증가율은 감소하고, t가 K에서 멀수록 증가율은 커진다. 따라서 다음과 같은 그래프가 나오게 되는것이다.

 

이때, 위 그래프에서 TCP Reno(classic TCP)는 일시적으로 TCP CUBIC보다 더 빠르게 윈도 크기(cwnd)를 증가시켜 TCP CUBIC을 추월하는 것처럼 보이는 구간이 나타난다. 그러나 TCP Reno는 혼잡이 발생한 후 Wmax까지 회복하는 데 오랜 시간이 걸리기 때문에, 장기적으로는 TCP CUBIC이 더 빠르게 회복하고, 결과적으로 대역폭을 더 효율적으로 활용할 수 있다.

 

이러한 TCP CUBIC 방식은 Linux에서 사용되고 있다.

---

8. TCP와 congested "bottleneck link"

 TCP는 classic 방식이든 CUBIC 방식인든 보내는 속도를 어떤 라우터에서 packet loss가 일어날 때까지 속도를 증가시킨다. 이때, packet loss가 일어난 구간의 링크를 bottleneck link라고 한다.

 

 Congestion의 정보를 알기 위해 우리는 congested bottlencek link에 대해서 집중할 필요가 있다. 다음과 같은 상황이 있다고 가정해보자.

 

 위 그림에 대해서 설명하면, 가운데 빨간색 라우터가 congestion이 일어난 bottleneck link이다. 이때, source와 destination이 소통할 때, 반드시 이 bottleneck link를 지나야 한다면 어떻게 될까?

 

 위와 같은 상황이 온다면 sender가 아무리 보내는 양을 늘려도 전체 성능(throughput)은 더 이상 늘지는 않을 것이다.왜냐하면 bottlencek link의 queue 대기하는 시간은 바뀌지 않을 것이기 때문이다. 따라서, 무리해서 데이터를 보내게 되면 오히려 패킷 손실만 발생하게 된다.

 

 따라서, 보내는 데이터를 적절하게 조절해 bottleneck link를 적절히 채우지만, 넘치지 않도록 해야 한다. 즉, pipe를 채우되, 넘치지 않도록 조절해야 된다는 것이다.

 

 이 아이디어를 최초로 구현한 곳이 바로 Google이다. Google은 BBR(Bottleneck Bandwidth and Round-Trip propagation time) 이라는 delay기반 혼잡 제어 알고리즘을 제안했다.

 

 BBR의 아이디어는 다음과 같다.

• sender-to-receiver pipe를 충분히 가득차게 유지하지만, 넘치지 않게 유지한다.
• 즉, bottleneck link는 계속 바쁘게 데이터를 전달하지만,  delay나 버퍼링이 발생하지 않게 유지한다.

 이 아이디어는 RTT를 기반으로 설계되었다., 혼잡 정도가 클수록 RTT도 당연히 커질 수밖에 없으니 RTT를 통해 혼잡 수준을 간접적으로 파악할 수 있는 매우 효과적인 아이디어이다.

 

  실측방법은 다음과 같다.

• RTTmin : 혼잡이 없는 상태에서의 관측된 RTT 중에 RTT의 최솟값
• 혼잡이 발생하지 않은 상태에서의 throughput = cwnd/RTTmin.
• 현재 측정한 throughput = last RTT interval / RTTmeasured                                                                                            (마지막에 보낸 byte 수를 RTT를 그 당시 측정했던 RTT로 나눠주면 현재 throughput이 나온다.)

이때,  두 가지 상황이 존재하는데,

1. 만약 현재 측정한 throughput이 혼잡이 발생하지 않은 상태에서의 throughput과 매우 가깝다면, RTT가 작은 것이니 혼잡하지 않다고 판단해, cwnd를 선형적으로 증가시킨다.
2. 또는, 현재 측정한 throughput이 혼잡이 발생하지 않은 상태에서의 throughput보다 매우 작다면, RTT가 큰 것이니, 혼잡하다고 판단해 cwnd를 선형적으로 감소시킨다.

 Delay-based TCP congestion control에 대해서 정리해보면,

• 패킷 손실 발생 전에 미리 혼잡을 감지하여 제어하는 방식
• throughput 최대화하고 delay를 최소하하려는 방식
• 매번 RTT를 이용해 throughput을 측정하고, 전송량을 미리 조절하는 방식

위 세 가지로 특징할 수 있다.

---

9. TCP ECN(Explicit Congestion Notification)

 앞서 살펴본 TCP의 혼잡 제어 방식들은 모두 implicit 방식이다. 즉, TCP는 네트워크 상에서 혼잡이 어디에서 발생하는지 직접적으로 알 수 없고, 패킷 손실이나 RTT 증가와 같은 간접적인 정보를 바탕으로 혼잡을 추정하여 congestion control을 수행한다.

 

 그렇지만, 이번에 정리할 TCP ECN(Explicit Congestion Notification) 방식은 앞선 방식들과는 달리 router가 직접 혼잡 상황을 송신자에게 알려주는 방식이다. 

 

 먼저 다음 그림을 살펴보자.

 

가운데 빨간색 router는 bottleneck link라고 하고, 위 그림에 대해서 설명하면

• sender측에서 IP header에 포함되어 있는 2bits짜리 ECN field 값을 10 상태로 보낸다.                                                  (이때, ECN=10은 해당 패킷이 ECN을 지원한다는 것을 의미하는 bits)
• 이때, 혼잡이 발생한 라우터(빨간색 라우터)를 지나게 되면, ECN = 11로 바뀐다.
• ECN = 11로 바뀐채, receiver에게 도착하면, receiver는 도중에 혼잡을 경험했다고 판단하고,
• TCP header의 E(ECE) field = 1로 설정한 뒤, ACK를 보낸다.
• 해당 ACK를 받은 sender는 혼잡이 있다고 판단한 뒤, cwnd를 감소시키는 등 혼잡제어 알고리즘을 실행한다.

---

10. TCP fairness

 TCP congestion과 관련된 마지막으로 정리해 볼 주제는 TCP fairness이다.

 

 만약, K개의 TCP connection이 동일한 bottleneck link의 대역폭 R을 공평하게 나눠쓰려면 각 연결은 은 이론적으로 R/K을 사용하는 것이 이상적이다. 예를 들어,

 

위 그림과 같이 2개의 TCP connection이 bandwidth가 R인 bottleneck router를 사용한다면, 각 연결은 R/2씩 사용해야 한다.

 

 그렇지만, 위 그림에 대해

• TCP connection 1 = A 사용자가,
• TCP connection 2 = B 사용자가 사용하고 있고,

B가 추가적으로 9개의 TCP connection을 연결해 총 10개의 TCP connection을 사용한다고 가정해보자. 이렇게 되면, 사용자 A는 R/11, 사용자 B는 10R/11을 사용하게 된다. 이렇게 되면 과연 TCP fairness가 성립한다고 볼 수 있을까? 

 

TCP의 fairness에 대해서 조금 더 자세히 알아보기 위해 다음 그래프를 먼저 살펴보자 .

 

위 그래프에 대해 설명하면,

• x 축 : conncection이 1개일 때의 throughput
• y 축 : conncectiondl  2개일 때의 throughput
•  bandwidth가 R인 bottleneck link를 공유한다고 가정(x+y<=R을 항상 만족해야 한다.)

이 그래프는 두 개의 TCP 연결이 동일한 bottleneck 링크(R)를 공유할 때, 각 연결이 얼마나 throughput을 사용하는지를 나타낸 것이다.

 

 이 그래프의 파란색 선은 x + y <= R을 나타낸 것으로, throughput의 한계선을 의미하고, 점선은 y = x 를 나타낸 것이로, Equal bandwidth share라고 부르고, 두 개의 conncection이 동일한 양만큼 대역폭을 사용하는 이상적인 상태이다. 

 

  그래프의 빨간 점에서부터 대역폭을 나눠쓴다고 가정해보자(추가로 AIMD를 사용한다고 가정해보자). 이 시점에서는 한 쪽이 일방적으로 대역폭을 많이 사용하고 있는 상태이다. 이때, 다음과 같이 일이 진행된다.

1. 빨간 지점에서 네트워크 사용량이 점점 늘어나 결국 R(파란 그래프)을 넘어간다.
2. 이때, loss가 발생하면 congestion control이 일어난다.
3. AIMD에 의해 cwnd가 각각 반으로 준다.
4. 다시 증가시키며 1~3의 과정을 반복한다.

위와 같은 순서로 진행되면서 점점 equal bandwidth share로 근사하게 되며 TCP fairness가 유지될 수 있다.

 

 여기서 생기는 의문점은, 처음에 불공정하게 나눠쓰고, 똑같이 반으로 줄이면 더 쓰는 쪽과 덜 쓰는 쪽의 편차가 점점 더 커지지 않을까 였다.

 

+) 그렇지만, 예를 들어 생각해 보면, A가 10을 사용하고 있었고, B가 2를 사용하고 있었다. congestion이 발생해 둘다 반으로 줄고, A=5, B=1이 된다. Congestion control 후 증가하면, A=6이 되고, B=2가 된다. 이때, 증가율로 따져보면, A는 20%가 증가했고, B는 100%가 증가했다. 이렇게 되면, B의 증가율이 당연히 커지게 되고 결국 둘은 equal bandwidth share로 가까워진다는 것을 확인할 수 있다.

 

 모든 상황이 위와 같이 이루어 진다면, TCP는 fair하다고 말할 수 있다.

---

11. More about Fairness

그렇다면, 모든 인터넷 애플리케이션은 공정하게(fair) 설계되어 있을까?

 

 먼저, UDP에 대해 생각해보자. 

• TCP는 혼잡제어를 통해 전송 속도를 줄이기 때문에 멀티미디어 앱은 보통 TCP를 사용하지 않고 UDP를 사용한다.
• UDP를 사용하는 이유는 UDP는 고정된 속도로 데이터를 보내고, packet loss가 일어나도 속도를 유지하기 때문이다.
• UDP는 혼잡제어 시스템이 없어 네트워크를 과도하게 사용할 가능성이 있다.

 이런 UDP를 제제할 수 있는 Internet Police가 존재하지 않기 때문에 공정성을 무너뜨릴 수 있다.

 

 TCP에 대해서 생각해보자.

• 어떤 앱은 동일한 호스트가 여러 개의 TCP 연결을 동시에 열 수 있다.
• 예를 들어, 9개의 TCP 연결이 존재하는 bandwidth가 R인 link가 있다고 가정하고,
  • 새로운 앱에 대해 1개의 추가적인 TCP 연결이 들어오면, 각각은 R/10을 나눠쓰게 되는데,
  • 새로운 앱에 대해 11개의 추가적인 TCP 연결이 들어오면, 그 사용자는 총 11R/20을 차지하게 된다.

 즉, 앱이 TCP 연결 수를 늘리면 대역폭을 더 많이 차지하게 되며, 공정성을 무너뜨릴 수 있다.