CH3 : Transport Layer (5)

* 이 글에 관련된 모든 내용은 Computer Networking A Top-Down Approach 7th에서 가져온 내용이다. *

 

Congestion Control

---

이미 여러번 언급했지만 이번강의에서는 congestion control에 대해 자세히 알아본다.

 

Congestion

라우터가 처리할 수 있는 용량보다 많은 packet이 들어오게 되면 congestion이 일어난다.

 

congestion이 일어나면 크게 두가지 상황이 발생한다.

1. packet loss (라우터의 buffer가 overflow가 나서 패킷이 로스된다)

2. long delays (라우터의 queue가 매우 혼잡하여 처리과정이 느리다)

 

이러한 문제가 발생하지 않게 사전에 예방을 해야하는데 방법은 sendring rate를 줄이는 수밖에 없다.

생각해보면 당연하다. 라우터가 지금 packet을 받을 여건이 안되면 다른 방법이 있는가? 그냥 덜보내야지..

이때 어떤 패킷이 들어올때 그리고 어떻게 줄일지에 대해 공정성과 효율성을 최대한 잘 생각해야한다.

 

그러나 단순한 방법으로 sender의 rate를 낮춰버리면 다음과 같은 상황이 발생할 수 있다.

라우터 A에서는 빨간패킷이 점유를 해서 파란패킷은 거의 못보내지고 있다.

라우터 B에서는 파란패킷이 점유를 해서 분홍패킷이 거의 못보내지고 있다.

라우터 C에서는 초록패킷이 점유를 해서 빨간패킷이 거의 못보내지고 있다.

 

파란패킷 기준

 - hostB로부터 출발하여 라우터 B에서 거의 점유를 해서 잘보내진 후에 라우터 A로 갔는데 빨간패킷 때문에 도착지로 전송이 안됨.

 

빨간패킷 기준

 - hostA로부터 출발하여 라우터 A에서 검의 점유를 해서 잘보내진 후에 라우터 C로 갔는대 초록패킷 때문에 도착지로 전송이 안됨.

 

 

이런식으로 서로가 서로때문에 도착지로 못보내지는 상황이 발생한다. (throughput = 0)

또한 제대로 보냈는데 라우터의 congestion control때문에 아직 못보내지고 있는건데 로스가난걸로 간주하여 불필요한 재전송이 많아진다.

 

 

 

우리는 최대한 throughput과 delay가 knee축에 맞는 정도로 congestion control을 해야한다.

 

 

Approaches

congestion control의 아이디어에는 크게 두가지가 있다.

 

1. Implicit congestion control

 - 라우터는 congestion이 발생했다는 것을 src에게 알려주지 않는다.

 - src는 라우터쪽에서 congestion이 발생한 것 같으면 send rate를 낮춘다.

 - 만약 congestion이 아닌 packet loss가 나도 congestion이 발생한 것으로 간주할 가능성이 있다.

 - 때문에 실제 pacekt loss가 많은 wireless에서는 잘 쓰이지 않는다.

 - TCP에 주로 사용된다.

 

2. Explicit congestion control

 - 라우터는 congestion이 발생하면 src에게 알려준다. (가장 이상적인 방법)

 - 이때 src에게 congestion이 발생했다는 것을 알려주는 데에는 두가지 방식이 있다.

     1. BECN : 라우터쪽에서 src쪽으로(뒤로) 알려준다. 그러나 이미 congestion이 발생했는데 또 뒤로 congsetion이 발                    생했다는 packet을 보내는데에는 살짝 무리가 있다.

     2. FECN : 라우터는 congestion이 발생할것 같은 packet에 마킹을 해두고 마킹해둔 packet을 받은 receiver가 sender
                  에게 알려준다. BECN방식의 문제점을 해결한다.

 - ATM, IP: ECN, DECbit에 사용된다.

 

 

TCP Conestion control

---

 

A window-based congestion control

- 아주 간단하게 sending rate를 계산해보면 윈도우 사이즈를 RTT로 나눈 값일 것이다.

RTT는 대부분 상수값이라고 봐도 무방하기 때문에 sending rate를 control하기 위해선 control window size(cwin의 size)를 줄이거나 늘리면서 control을 해야한다.

 

이때 중요한 issue는 다음과 같다.

1. congestion을 어떻게 판단하는가? (TCP에서는 timeout이거나 duplicate한 ACK이 오면 congestion으로 판단한다)

2. cwin size를 얼마나 줄이거나 늘려야하는가?

 

앞서서 congestion control에서는 공정성과 효율성에 대해 생각해야한다고 했다.

두명의 유저(User1, User2)가 있다고 생각해보자.

 

우선 효율성을 위해서라면 User1의 rate와 User2 rate가 전체 bandwidth가 된다면 꽉찬 효율을 낼 수 있다.

이렇게 기울기가 -1인 일차함수꼴로 표현이 된다.

 

또한 공정성을 위해서라면 x1(User1 rate)과 x2(User2 rate)가 같아야 할것이다.

이렇게 기울기가 1인 일차함수꼴로 표현이 된다.

이때 여러 유저에 대해 공정성을 알기위한 식은 다음과 같다.

만약 모든 유저의 rate가 같다면 F(x)의 값은 1이 될 것이다.

 

때문에 종합해보면 다음 지점에서 공정성과 효율성을 만족한다.

 

 

Congestion control 메커니즘에는 다음과 같이 네개의 경우의 수가 존재한다.

이때 위 세개는 마지막 AIMD만 stable하다고 한다.

stable하다는 것은 위에서 말한 여러 네트워크 상황이 빨간점으로 수렴한다는 것이다.

 

해당 AIMD를 이용해 공정성과 효율성을 평가해보면 다음과 같다고 한당

 

 

Congestion control mechanisms (TCP)

---

TCP에서 사용되는 congestion control의 메커니즘은 크게 3가지로 나뉜다.

 

1. Slow start

초기에 sender가 데이터를 보낼때 congestion이 발생할지 안할지 모르기 때문에 매우 조심스럽게 작은 크기를 먼저 보내본다는 아이디어이다. (MSS를 작게)

 

이때 만약 기존 사이즈로 보냈던 데이터가 잘 전송이 되면 사이즈를 급격하게(2배씩) 늘려가며 전송해본다.

때문에 이름은 slow start지만 절대 slow하지 않다.

2. Congestion avoidance

SS에서 어느정도 크기를 늘렸으면 Congestion Avoidance모드에서는 다음과 같은 과정을 따른다.

이때 SS에서 CA로 넘어가는 조건은 ssthresh라는 변수를 두어 현재 cwnd가 ssthresh보다 작다면 SS과정을 하고 그렇지 않다면 CA모드로 넘어간다. (cwnd = 현재 윈도우 크기)

 

현재 MSS내에 있는 모든 segment를 보냈을 때 ack이 정상으로 오면 MSS를 1씩 늘린다.

만약 돌아오지 않았다면 ssthresh = (cwnd)/2를 하고, cwnd=1로 초기화한 후 다시 SS과정으로 돌아간다.

 

이 과정(SS부터 CA)을 그래프로 그려보면 다음과 같다.

 

3. Fast retransmission/recovery

비교적 최근에 fast recovery 기능이 추가되었다. 

 

이 아이디어는 간단히 말해 SS과정을 skip하자는 것이다.

만약 3 duplicate ACK이 도착하면 fast retransmission으로 간주하고 

ssthresh = max(FlightSize/2, 2MSS)

cwnd = ssthresh + 3MSS

로 초기화한다.

 

또한 다음 ACK(acknowledges new data)가 도착하면 fast recovery mode를 종료하고 cwnd = ssthresh로 해준다.

과정을 잘 따라가보며 이해해보장

 

 

TCP Tahoe는 SS와 CA까지 구현된 것이고

TCP Reno는 Fast recovoery기능까지 추가된 것이다.

보편적으로 Reno가 Tahoe보다 성능은 좋지만 loss가 많이 발생하는 경우에는 Tahoe가 더 좋은 performance를 보여주는것을 확인할 수 있다.