[ 네트워크 ] 15. Transport layer : TCP ( Congestion Control )

TCP Congestion Control

3가지 방법이 있다.

• Slow Start
• Congestion Avoidance
• Fast recovery / Fast Retransmission

 

Varialbes

• cwnd : Congestion Window
• ssthresh : Slow-Start threshold = 이 이후로는 위험할 수도 있으니 천천히 늘려라...
• rwnd : Receiver's Advertised Window

---

Slow Start

: 첫 Loss가 나기 전까지 Rate를 2배로 올린다.

 

- 시작할 때 : cwnd = 1 MSS

- 매 RTT마다 ACK 를 받으면 보내는 cnwd를 2배로 늘린다.

 

 

➡️ 첫 Rate 는 천천히 낮게, 점점 Exponentially 하게 증가시켜 Rate를 올린다.

 

누울 자리 보고 , 문제 안 생기면 조금씩  

 

 

 

Congestion Avoidance

Slow start로 시작해서 계속 Rate를 올리다가

Packet Loss가 발생했을 시에는 해당 Rate 의 절반으로 줄인다.

 

AIMD : Additive Increase + Multiplicative Decrease 

           = 더 보내는 건 하나씩 늘려간다.  + 감소량은 곱으로 줄어든다.

          ➡️ 증가는 스멀스멀, 빠질 땐 확 빠진다.

         

Multiplicative Decrease도 종류가 있다.

 

- Timeout : MSS를 1까지 내린다.

- Duplicate triple ACK : Rate를 반토막낸다.

 

우리는 한 번 보낼 때 cwnd만큼 보낼 수 있다.

하지만 이게 ACK로 한 번 갔다 와야 다시 또 보낼 수 있기 때문에

 

TCP rate = cwnd / RTT 가 된다. 

*네트워크 상황에 따라 Dynamic하게 바뀐다. 

 

 

 

 

 

 

- ssthresh 가 시작할 때 정해져있다.

  ➡️ ssthresh 전까지는 cwnd가 2배로 증가한다.

        + sshthresh < = cwnd 일 때부터는 cwnd가 1씩 증가

 

-Timeout 발생

  ➡️ cwnd = 1

  ➡️ sshtresh = Timeout 발생할 때의 cwnd/2

 

 

따라서 

 

- sshthresh 보다 cwnd가 작을 때는

➡️ Slow-start 방식을 따라, Exponentially하게 값을 증가시킨다.

 

 

 

- sshthresh 보다 cwnd가 같거나 클 때는

➡️ Congestion Avoidance 방식을 따라, Additive Increase + Multiplicative Decrease 시킨다.

 

 

📌요약

아는 길(에러 없는 영역)은 확확 걸어가고

위험한 길(에러 가능성이 있는 영역)은 천천히... 문제있으면 확 도망

 

 

+ TCP Tahoe(초기 버전) : timeout 발생하면 ssthresh 를 현재 rate의 절반으로 하고, cwnd =1

+ TCP Reno (수정 버전) : timeout 발생하면 ssthresh 를 현재 rate의 절반으로 하고, cwnd = ssthresh

 

 

---

TCP Throughput

 

Slow start 를 생각하지 않고 중간 단계부터 생각하자.

 

Loss가 발생하는 부분의 Window size를  W라고 했을 때

평균적으로 왔다갔다 하는 건 

- 최대 = W ( 에러가 여기서 나니까 )

- 최소 = W/2 (에러 나면 반토막 나니까)

➡️ 평균은 ((3/4)*W) / RTT 가 나온다.

 

 

 

높은 대역폭을 유지하면서  Long pipe를 통한 소통 (장거리 소통)을 빠르게 하기 위해선

극단적으로 낮은 Loss율이 필요한데, 사실상 이건 거의 불가능하다고 봐야한다.

 

➡️ 새로운 방법이 필요함.

 

 

 

---

Bandwidth, 즉 어디쯤에서 Congestion Loss가 나는지 아는 걸 AIMD보다 더 좋은 방법이 없나 찾아봤음

 

CUBIC

- Wmax : Congestion Loss가 발생하기 시작하는 Sending rate

   ➡️ Loss 발생 시에 반으로 줄어드는데, Wmax 근처까지 확 올라갔다가 그 근처에 다다르면 속도를 줄인다.

 

 

 

파란색 선을 보면 점진적으로 오르는 게 아니라

가파르게 올라갔다가 Wmax에 가까워지면 속도를 늦추는 방식이다.

 

- K : TCP window 사이즈가 Wmax에 다다르는 시간 Point

 

➡️ K에서 멀면 : 급격하게 Window 사이즈 증가

      K에서 가까우면 : 조금씩 Window 사이즈 증가

 

 

---

Congestion이 발생 여부에 대해서 명시적으로 알 수 있는 방법

라우터가 Congestion Control을 도와줄 수 있다.

= Network-assisted

 

- IP 헤더에 2비트를 사용하여, router가 congestion이 발생했는지 알려준다. ( = ECN )

- ACK Segment에 ECN Echo 비트를 세팅해두어, Congestion을 파악할 수도 있다. 

 

 

---

TCP Fair(ness)

: 여러 개의 TCP 연결이 있을 때, 모두가 같은 Bottleneck Link 를 갖는 것

 

 

- K 개의 TCP sessions

- Bandwidth R

 

➡️ 평균 Rate = R / K

그냥 같은 크기를 인원수만큼 나누어 가진다.

 

 

Q. 이거 항상 Fair함??

A : 이상적인 상황에서만 Fair함.

- Same RTT

- Congestion Avoidance가 발생하는 고정된 숫자의 Session

 

 

 

> 빨간 점에서 시작

 

1. Congestion Avoidance - Additive Increase 이기 때문에

   계속해서 처리율이 올라간다.

 

2. 처리율이 올라가다가 R/K 를 지나서 Loss가 난다면 다시  [ 현재 처리율 /2 ] 로 돌아간다.

 

3. 다시 반토막난 처리율에서 Additive Increase 해서 올라간다...

4. 넘어서 반토막...

5. ...반복

 

➡️이 과정을 계속해서 거친다면 두 TCP session 이 같은 처리율을 갖는 중간지점을 만난다.

     = Equal bandwidth share point에서 멈춘다.

 

 

 

---

Q. 모든 프로그램이 Fair해야함??

1. UDP 는 공평하지 않다.

- 다른 연결들과 따로 소통하지 않기 때문에 전송률을 조정할 필요가 없다.

- 일정한 속도로 보내는 것을 목적으로 UDP를 사용하기 때문에 패킷 손실을 감수하고 Fair포기

* UDP에는 Congetstion Control과 관련된 정책이 없기에 가능하다.

 

 

2. 병렬적 TCP 도 공평하지 않다.

> TCP 기반 어플리케이션이 병렬로 연결되어있는 경우 / 9개 TCP 연결이 되어있는 상황/ 대역폭은 10개 단위로 열린다

- 새로운 1개의 TCP 연결이 들어온 경우엔 R / 10 을 받는다.

- 새로운 11개의 TCP 연결이 들어온 경우엔 R / 2 을 받는다.

   ➡️ 20개의 연결 -> 11*(R/20) =~ R/2가 나온다. 

 

 

즉, 네트워크를 사용한 모든 통신이 Fair하지 않고, 그럴 필요도 없다.

---

Transport 계층 기능의 발달

 

 

 

 

📌 QUIC ( Quick UDP Internet Connections )

: HTTP 성능 향상을 위한 UDT기반 프로토콜

 

 

기능)

1. Error and Congetsion Control

  : 에러를 감지하고, 혼잡 제어 기능을 제공한다.

 

 

2. Connection Establishment

    : 한 번의 RTT를 통해서  [ 연결 구축 +혼잡제어 + 인증 + 암호화 + 안전한 통신 ] 을 수행한다.

 

 

 

3. No HOL Blocking

    : 1,2,3 패킷이 있다.

      2번에서 Error가 나면 3번은 뒤에서 계속 기다리고 있어야한다. 이 상황을 HOL Blocking이라고 하는데

     QUIC는 이런 거 없이 앞에서 에러가 나도 그냥 옆으로 피해서 지나간다.

 

 

 

(출처)

한동대학교 고윤민교수님 - 컴퓨터 네트워크