[네트워크] TCP 혼잡제어

a. 혼잡

혼잡의 원인 : 라우터에 들어오는 양이 처리량보다 더 커서.

딜레이가 길어지고, 패켓을 잃을 수 있음.

 

라우터의 버퍼가 무제한이라고 가정하면. 데이터 전송이 계속 커질 수록, 데이터 전송 능력(throughput)능력은 같이 오르다가 한계 이후는 정체된다.

센더 두개 리시버 두개 라우터 하나 상황 가정

이론적으로 인풋량이 늘면 처리량도 한계치까지는 비례해서 증가. / 입력량이 데이터 최대 처리능력에 가까워질수록 딜레이 증가.

 

하지만 현실엔 다름(라우터 버퍼가 유한함)

실제로 유효하게 받은 데이터 처리량을 goodput이라고 한다.

혼잡이 발생하면 라우터에서 로스가 발생-수신자가 재전송-이럴 경우 재전송 데이터는 goodput에는 포함되지 않음.

즉 혼잡이 발생하면 goodput과 throughput이 차이가 나게 된다!

 

여러 센더가 라우터들을 공유하면서 정보를 전송할 때

g호스트 D가 B를 향해 데이터를 주고, A가 C를 향해 데이터를 전송한다고 가정.

이때 R1라우터를 같이 사용하게 된다.

이때 A가 데이터 전송량을 늘리게 되면? B가 받는 정보량이 줄어들게 된다.

그리고 R1에서 생긴 패캣로스를 다시 재전송하게 되면 R4는 억울하게 정상적으로 했던 일을 다시 또 하게된다.

이를 upstream trasmission cpacity의 낭비라고 한다.

 

b. 혼잡 제어

TCP의 혼잡제어는 해당 라우터를 사용하는 모든 참가자가 다같이 속도를 내리는 방식.

 

b-1. additive increase multiplicative decrease AIMD방식

congestion avoidance 상태에서 적용(전송이 어느정도 진행되고 있을 때 너무 많은 데이터전송을 막음)

센더는 네트워크의 혼잡도를 잘 모르니 작은 데이터 먼저 한번 보내보고,

잘 보내졌음을 알게되면, 더 많은 데이터를 보내보고,

이 또한 잘 보내졌으면, 더욱 많은 데이터를 보내고...

(딜레이나 로스가 발생하게 되면 전송률을 낮춰서 다시 반복)

 

센더는 cwnd(혼잡제어 방식에 있어서 보낼 수 있는 데이터량), rwnd(플로우컨트롤에 의해 보낼 수 있는 양)), sender widow(rdt에서 보낼수 있는 데이터량) 중 가장 작은 값만큼 데이터를 보내기로 정한다.

TCP sending rate = cwnd/RTT(대략적으로)

 

b-2. TCP slow start

slow start는 센더가 맨 처음 데이터를 한 세그먼트만 보내보는 것을 의미.

잘 보내졌으면 두 세그먼 트를, 그 다음엔 네 세그먼트를... 이런식으로 2^n를 하며 전송 데이터를 늘려감.

이렇게 데이터를 늘려가다가 혼잡하게 되면, AIMD로 제어. 

초기엔 cwnd= 1 mss(최대로 보낼 수 있는 세그먼트량)

매 RTT마다 두배로 늘림.

 

c. 데이터 전송 줄이기

timeout이 발생하거나, 중복된 ack가 세번오면 로스로 간주한다.

 

timeout이 발생 시(TCP Tahoe, 구버전), 전송량(cwnd)를 1mss로 재설정함. 다시 slow start 과정을 진행시킴.

slow start 이후로 어떠한 임계값(threshold, 정해진 변수)보다 전송량이 커지게 되면, 선형적으로 증가함.

TCP Tahoe는 항상 cwnd를 1mss로 만듬(다른 방식을 지원 안하니..)

 

중복 ack가 세번 온 경우(TCP RENO , 신버전), 전송량(cwnd)를 절반으로 낮춤. 그리고 나서 선형적으로 증가(slow start)아님.

 

Tahoe와 Reno에 따른 대응

상태	이벤트	TCP 센더 대응	비고
Slow Start(SS)	전에 보낸 데이터의 ack를 정상적으로 받음	cwrd가 threshold보다 큰 경우 CA로 변환	매 RTT마다 cwrd를 두배로
Congestion Avoidacne(CA)	전에 보낸 데이터의 ack를 정상적으로 받음		매 RTT마다 cwrd를 1 mss씩 증가(additive increase)
SS or CA	중복된 ack를 세번 받음 (로스 감지)	threshold를 cwrd의 절반으로 cwrd를 threshold로 하고 CA로 변환	Fast Recovery(threshold부터 증가)
SS or CA	timeout(로스 감지)	threshold를 cwrd의 절반으로 cwrd를 1mss로 하고 slow start 상태로 전환	slow start 진행
SS or CA	중복된 ack	duplicate ack 카운트만 증가	cwrd나 threshold는 변경 안함

 

d. TCP throughput

throughput = 시간당 전송률

TCP의 throughput은 복잡하므로 간단한 가정이 필요.

slow start 상태는 제외, 항상 보낼 데이터가 존재함을 가정.

w=로스가 발생할때 cwrd

평균 cwrd는 3/4w

평균 throughput은 3w/4rtt

 

이때 가정을 제외하고 현실적인 Throughput은

이때 L은 로스 발생 확률이다.

 

e. TCP Fairness

TCP는 여러 사용자가 라우터를 이용하면 결과적으로는 동일한 양의 리소스를 사용하게 된다.

두 TCP사용자가 한 라우터를 이용하고, 라우터의 처리양이 100이라고 할 때,

(60,20)-전송량 증가-(80,30)-로스발생(값 절반으로 나눔)-(40,15)....이런식으로 가면 결국 (50,50)이됨.

 

e-1 TCP Fairness의 한계

UDP와 라우터를 공유하는 경우

-UDP가 자원을 더 가져갈 수 있음!

TCP를 여러개 사용할 때(여러 프로세스 사용)

-여러 TCP를 운용하는 호스트가 자원을 더 가져갈 수 있음!

 

e-2 Explicit Congestion Notification

혼잡이 아닌 다른 경우에 ack를 받지 못하는 경우도 존재한다.

근데 이런 경우에도 속도를 줄이는 것은 비효율적!

 

이를 해결하기 위해 네트워크에서 혼잡을 일으킨 호스트에게 혼잡임을 알리게 하자.

IP헤더의 Tos필드에 혼잡여부를 기록해서 센더에게 전달!

하지만 많이 사용되지 않음(모든 라우터가 이 기능을 갖춰야하기때문에..)