3-5 TCP Congestion Control

Congestion control 의 원칙

congestion : “네트워크”가 감당할 수 있는 것보다, 너무 많은 데이터를 너무 빨리 밀어넣는 것

flow control - receiving buffer에 대한 것

 

long delay ( queueing in router buffer) 

lost packet ( buffer overflow at router buffer)

네트워크에 congestion이 발생하면 delay가 커지게 되고,

congestion이 더 극심해지면 packet loss가 발생하게 된다.

 

 

Congestion control 발생 시나리오

선 색깔 따라서 보기

 

ACK이 오지 않아서 발생한 timeout에 대해 retransmit을 한다면...

(조금 늦게 도착한 케이스거나 진짜 loss 거나, ack의 loss거나)

 

(가정)

람다 in) application이 생성하는 (original) data rate

람다 in prime) application이 생성하는 (original) data rate + retransmitted data

 

이 두가지가 점진적으로 늘어난다면?

'람다 in'이 늘어나면 '람다 in prime'도 늘어남

router의 buffer에 채워지다가 timeout 발생

 

'람다 in prime'이 늘어나면 한 쪽의 throughput->0이 됨

빨간선이 처음 지나는 router에는 파랑선도 지나감

빨간선의 data rate가 급격히 늘어나면,  파랑선에선 data drop을 겪게 됨

blue는 packet drop으로 인한 throughput = 0이 된다

이렇게 겹치는 곳은 상대적으로 한 쪽이 안 좋아질 수 있다

'람다 in prime'이 늘어나면 '람다 out' (throughput)도 증가

아래 그래프에서 c의 의미는 router의 capacity.

'람다 out'은 최대 c/2까지밖에 ( 그 router에 flow가 2개가 있으니까 "/2")

'람다 in prime'에서 restransmit이 더 증가하면 c/2에 증가하며 

꺾여서  '람다 out' (throughput)이 감소

 

<congestion에서 비용이 발생하는 부분>

delay로 인한 불필요한 retransmission - link에 동일한 packet -> goodput 감소

goodput을 위해 또 더 보내니,,,

결국 쓸데없는 packet에 upstream transmission capacity를 낭비하게 됨

 

Congestion 해결 방법 2개

end-end congestion control

network로부터 어느 종류의 feedback도 없음

단지 end system이 loss,delay를 통해 congestion을 추측

 

TCP의 접근법

(현재 보편적으로 사용되고 있는 TCP는

네트워크에 혼잡이 발생했을 때 이것을 end-to-end로 해결한다.)

 

network-assisted congestion control

router가 end system에 피드백을 제공

• single bit flag로 congestion 여부 표시
  • TCP/IP ECN: 보완 버전. drop 발생 전에 큐를 보고 판단 
  • ATM : 얘는 single bit도, explicit bit rate를 상황에 따라서 함
• router 입장에서 sender에게 특정 bit rate로 보내달라고 요청

 

---

TCP Congestion Control

cwnd : congestion window size == TCP sender’s rate

네트워크의 congestion에 따라 dynamic한 값

 

lost segment

due to "timeout" or 3 dup ACK

• TCP sender’s rate는 감소해야 함
• 줄이기만 한다면 bandwidth를 다 사용하지 못하는 단점. 이를 올릴 수 있는 방법도 필요

 

Acknowledged segment

네트워크가 segment를 배달 중임을 표시

즉, 네트워크에 congestion이 없음을 앎

ACK이 오면 cwnd를 증가시킴

 

목표: TCP sender가 네트워크를 혼잡하게 하지 않고

이용가능한 bandwidth를 효율적으로 쓰는 것

 

방법: TCP sender가 transmission rate를 증가시키면

이는 congestion이 일어난다는 증거로 삼음.

그래서 다시 rate를 되돌리고 확인해본 뒤

congestion이 나아졌는지 검사

 

sender는 아래 식에 따라 전송을 제한하며 진행

즉 노란색 가장 뒤에서 가장 앞을 뺀 것

 

TCP sending rate:

cwnd 개의 segment를 back to back으로

ack도 받지 않은 상태에서 쭉 내보냄

이들에 대한 ack이 RTT를 통해 돌아옴

그래서 RTT 동안 cwnd개 만큼 보낸 것을 계산하면

sending rate를 알 수 있음

 

 

---

TCP congestion control : AIMD 

send rate를 야금야금 올려 나갈 때

얼만큼 올려나가는지에 대한 것

 

additive increase:

loss가 발생하지 않고 ack이 계속 들어오면

RTT마다 1 MSS만큼 cwnd 를 조금씩 증가시킴

보편적으로 1 segment가 MSS인 경우가 많으니

RTT마다 1 segment 증가시킨다고 생각해

 

multiplicative decrease

loss 발생 시 

cwnd를 반으로 급격하게 줄임

 

시간에 따른 cwnd 변화 그래프 - 마치 톱니모양

loss 발생 전까지 선형적으로 증가

loss를 만나면 반으로 감소

 

 

 

 

 

TCP slow start SS

처음 connection 시작 시에는 매우 조심스럽게 segment를 보냄

처음엔 하나만 보냄 : cwnd = 1 MSS

이를 RTT마다, 즉 ACK이 들어올때마다, 두 배씩 증가 시키기에

느리게 시작해도 금방 빠른 속도로 보내게 됨

 

 

 

 

 

 

TCP slow start SS - ssthresh

<ssthresh> : slow start thresh

cwnd의 증가 속도를 느리게 하기 위해 기준을 threshold(=한계값)로 설정

ssthresh를 처음에는 운영체제가 정하지만 

loss 발생 시 ssthresh를 cwnd/2로 지정 

이 시점 이후로는 congestion이 발생할 수 있기에 확 내린 뒤 다시 천천히 올림

 

<cwnd가 ssthresh에 도달하면>

CA 시작 : slow start를 끝내고 congestion avoid 상태로 돌입

addative increment 를 수행 ( RTT마다 1MSS만큼 cwnd 증가)

cwnd의 단위는 segment 수

ACK이 올 때마다 MSS/cwnd만큼 cwnd를 늘림

 

<요약>

TCP가 connection을 처음 열었을 때는 CWND=1,

ssthresh는 운영체제가 정하는 default value로 정함

ssthresh는 packet loss가 발생할 때 마다, 현재 CWND/2로 재설정된다.

 

cwnd < ssthresh

• slow start로 (매 RTT마다 cwnd 2배씩 증가시키기)

cwnd >= ssthresh

• congestion avoid로 ( 매 RTT마다 cwnd 1 MSS 씩  증가)