3-5-1. Principles of congestion control

TCP의 두 번째 부가적 기능 congestion control..

 

congestion control은 네트워크 혼잡도에 어떻게 대응하냐는 얘기다.

 

flow control은 하나의 sender와 하나의 receiver 간 문제에 관한 것이라면

congestion control은 너무 많은 sender가 receiver로 접근하는 상황에 관한 문제다.

 

 

Congestion scenario

 

Host A는 Host C로, Host B는 Host D로 보내는 상황이다.

두 transmission은 router들의 buffer을 공유하고 있다. 하지만 buffer의 크기는 한정적이므로 loss가 발생할 가능성이 있다.

예컨대 Host A에서 보낸 것 때문에 Host B가 보낸 것이 들어갈 큐의 자리가 없어 loss가 발생할 수 있다. Host A에서 보낸 것 또한 다음 router에서 다른 segment들로 인해 loss가 발생할 수 있다.

 

이 상황에서 어떤 비용이 발생하는가?

 

- 불필요한 loss가 발생하므로 다시 요청하기 위한 retransmit을 해야 한다.

- 그리고 loss 발생하지 않아도 발생했다고 간주하여 retransmit을 하게 될 수도 있다.

=> 결국 1번 보낼 것을 2번 보내는 상황이 발생하는 거다.

- 기어이 전 router들을 뚫고 온 것들이 나중에 loss되면 이전 router들의 큐는 헛소비된 것이다.

 

즉,,, goodput(끝까지 잘 전달되는 것)이 위의 그래프와 같이 그려지는 거다.

 

congestion control을 위한 두 가지 접근

 

1. network-assisted congestion control

: router들이 direct feedback 제공(congestion은 network에서 발생하기 때문)

: congestion level과 sending rate 또한 명시해야

=> feedback을 받을 수 있지만 담아야 하는 정보가 많기 때문에 heavy..

 

좀 더 자세히 살펴보자.

1. 네트워크가 congestion 정보를 제공할 때 ToS field에 정보를 써준다. (ECN=1)

2. ToS field('E', 'C')에 정보를 담은 segment가 destination으로 전달됨

3. destination이 ACK 보낼 때 ECE=1 이라고 전달함

4. source도 알게 됨

 

 

2. end-end congestion control(loss가 곧 congestion, ACK이 곧 non-congestion => ACK 올수록 속도 높임)

: feedback 제공하지 않음

: loss 와 delay를 통해 congestion 추정할 뿐

=> heavy 하지 않기 때문에 주로 사용

 

목표는 network congestion 발생시키지 않으면서 bandwidth도 최대로 활용하는 것이다.

 

- congestion 발생했다고 판단하는 경우

1. timeout 또는 3 dup ACK이 발생하면 loss 발생

2. loss가 발생하면 congestion이 발생했다고 판단

3. sending rate 낮춤(bandwidth 즉 cwnd를 줄임) => for congestion 낮추기

 

- congestion 발생하지 않았다고 판단하는 경우

1. ACK을 받으면 congestion이 발생하지 않았다고 판단

2. sending rate 높임(bandwidth 즉 cwnd를 늘림) => for bandwidth 최대 활용

 

 

 

**cwnd 는 ACK되지 않았거나 보내지지 않은 (노란색+파란색) byte들의 최대량

다음과 같이 노란+파란이 cwnd를 넘지 않도록 해야 한다!!

LastByteSent - LastByteAcked <= cwnd

(TCP sending rate) ~= (cwnd/RTT) (bytes/sec)

 

 

"end-end congestion control에서 sending rate 늘리거나 줄이는 방식"

sending rate를 늘리거나 줄일 때는 어떤 양상으로 조절을 할까?

 

1. AIMD(Additive Increase Multiplicative Decrease)

: 늘릴 때는 additive로 조심스럽게, 줄일 때는 multiplicative로 확 줄인다는 거다.(늘리는 건 1개씩 줄이는 건 반으로)

=> 톱니바퀴 형식의 그래프로 보여짐

 

2. TCP Slow Start(SS)

: "cwnd가 ssthresh 도달하기 전까지는 multiplicative

ssthresh에 도달하면 additive

처음 loss가 발생하면 ssthresh를 반으로 줄임

그리고 loss가 한동안 발생하지 않으면 조금씩 늘려나감"

 

예컨대

처음에는 보수적으로 하나만 보냄 => ACK 받음(cwnd=2개 됨) => 2개 내보냄 => ACK 2개 다 받음(cwnd=4개 됨) => 4개 내보냄 

 

따라서 처음에는 조금 받지만 나중에는 어마어마하게 많은 양을 처리할 수 있다.

 

하지만 언제까지 값을 늘려나갈 수는 없다. 그 한계점을 정해야 하는데 ssthresh라고 하고 이는 운영체제가 정해준다.

ssthresh에 도달하면 multiplicative이 아니라 additive 으로 바뀌는 거다.

 

그리고 loss가 발생하면 ssthresh를 현재 cwnd의 반으로 줄인다.