[네트워크] Chap 3.8 - TCP congestion control & TCP fairness

TCP congestion control : details

 

Window size (W=min(rwnd,cwnd))의 의미

• sender(send TCP)가 receiver(receive TCP)로부터 new ACK을 받지 않고도 보낼 수 있는 최대 byte 수
  (ex. 노란색 부분 byte 수 => the maximum number of in-flight (unacked) bytes)

TCP sending rate ≒ (cwnd bytes sent per RTT sec.) = cwnd / RTT

 

각 RTT 마다 send TCP가 수신하는 ACK 개수는 다르다.

그 개수를 N_ACK_RTT 라고 하면 그 값은 그 RTT에 전송된 segments 개수와 같으며, 그 값은 floor(cwnd/MSS)이다. 

(즉 몇개의 segment를 보냈는가? = 몇개의 ACK을 보냈는가? 랑 같은말)

 

Window가 옆으로 안움직이면? => Throughput은 안늘어남!

항상 new ACK을 받아서 옆으로 가야지 throughput이 늘어나는것

---

AIMD (Additive Increase Multiplicative Decrease)

증가시킬땐 천천히 증가시키고, 낮출때는 확 낮추자!

 

sender는 loss가 발생하기 전까지는 sending rate (Window size, cwnd)를 1 MSS 단위로 증가시킨다.

(각 RTT마다 하나의 segment만 증가시킨다!)

 

loss가 발생하면, sending rate를 절반으로 줄인다.

cwnd += 1 MSS / RTT

---

SS (TCP Slow Start)

말 그대로 좀 느리게 시작하겠다는 것. segment를 1개 보내는걸로 시작한다.

 

initial cwnd = 1 MSS 로 시작!

각 RTT마다 MSS가 double로 증가 (= ACK을 받을때마다 1 MSS 씩 증가)

=> 각 RTT마다 2배씩 증가 → exponential하게 전송 속도가 증가

cwnd x=2 per RTT

 

 

TCP: from slow start to congestion avoidance

 

Slow Start는 initla rate = 1 MSS (cwnd)로 시작해 ACK을 받을때마다 각 ACK당 1 MSS씩 증가시킨다.

(ssthresh에 도달할때까지)

 

cwnd가 ssthresh에 도달하면 (즉 loss가 생기면)

→ ssthresh를 cwnd값의 절반으로 줄인다

→ CA phase (Congestion Avoidance) 모드로 들어가, cwnd가 각 RTT당 1 MSS씩 증가한다 (여기부터 AIMD과 유사!)

---

TCP : detecting, reacting to loss;  Tahoe vs RENO

TCP Tahoe

얼마나 심각한 loss인지 아무 생각 없음 (loss를 구별하지 않음)
loss가 일어나면 3 dup ACK이든 timeout이든 다 Slow Start로 가버리겠다는것

 

TCP RENO

- timeout이 생기면? → 심각하다고 판단 → Slow Start로 들어가서 바짝 줄임
- 3 dup ACK이 발생하면, 네트워크가 괜찮다고 생각
  → cwnd를 절반으로 줄이고, Congestion Avoidance 시작 (1 RTT당 1 MSS씩 linear하게 증가)

 

Reno를 쓰는애랑 Tahoe를 쓰는애가 같은 link를 경쟁하면?

=> Reno가 더 많이씀 (Reno는 3 dup ACK은 네트워크가 그렇게 심각한 상황이라고 보지 않기 때문)

---

TCP CUBIC

W_max에 도착하면 loss가 생길거라고 학습

언제 loss가 생길지 k 값을 예측한다!

 

k : TCP window size가 W_max에 도달하는 시점

W_max에 도달할 때까지 빠르게 증가시켰다가, W_max에 가까이 도달하면 속도를 줄인다. 

 

CUBIC을 사용하여 기존의 TCP 보다 높은 throughput을 얻기 위해서는 loss 발생 시 절반의 값으로 조정된 cwnd 값이 얼마나 빨리 W_max(이전 loss 발생 시의 cwnd)에 도달할 것인지를 예측하는 알고리즘의 정확도가 중요하다.

---

TCP Fairness

Congestion Control의 goal
: throughput을 결정짓는 bottleneck에서 bandwidth를 얼마나 공정하게 share하는가?

 

TCP connection is fair only when RTT(A~R) = RTT(B~R)

즉, 위 그림처럼 2개의 TCP connection이 R capacity를 가지고 있는 라우터를 공유한다고 가정하자.

TCP fairness를 만족하기 위해서는, A, B가 각각 R/2의 bandwidth씩 공평하게 사용해야 한다.

 

=> 용량이 R인 라우터에 k개의 connection이 있다면 각 connection은 R/k씩 똑같이 사용해야한다!

---

Is TCP fair?

connection 1이 사용하는 window 양 (= cwnd, throughput) 이 늘어나면, connection 2가 사용하는 window 양은 줄어든다.

 

각 connection의 cwnd가 점점 증가하다가 파란선(R)을 넘어가면 loss가 생김!

loss가 생기면 (파란선의 바깥쪽으로 나가면) 각 connection의 cwnd를 loss가 생긴 시점의 절반으로 줄인다.

 

이를 반복하면, 결과적으로 connection1 과 connection 2는 각각 R / 2만큼의 bandwidth를 공평하게 쓰게 된다.

 

 

 

결론:

TCP가 fair하려면,

1. 두 connection의 RTT가 동일하고

2. 경쟁하는 bottleneck까지 가는 환경도 똑같아야 한다!

---

Fairness (more)

 

application 측면에서 TCP가 fair하지 않은 2가지 케이스

- When UDP and TCP users are mixed in the network

UDP와 TCP가 link를 공유하는 경우, TCP는 congestion control을 하므로 rate를 낮춘다. 하지만 UDP는 loss가 생겨도 그냥 보내던 속도 그대로 계속 보낸다. 결국 UDP가 TCP보다 bandwidth를 더 많이 사용하게 된다. 

 

- When some applications open multiple parallel TCP connections (non-persistent with parallel)

TCP만 link를 사용하는 경우라도, TCP connection이 non-persistent with parallel 방식이라면, bottleneck link을 TCP 입장에서 봤을때는 fair하지만, application 입장에서 보면 unfair (ex. 어떤애는 9개 사용, 어떤애는 1개 사용)