Shine's dev log
Congestion Control 의 개념 본문
1. Congestion
한국말로는 "혼잡"이다.
이름에서 유추할 수 있듯이 네트워크 상에 패킷들이 너무 많아서 혼잡이 발생하는 경우를 뜻한다.
congestion이 발생할 경우, 패킷이 라우터의 queue에서 손실되거나, delay가 너무 오래 발생해 재전송 되는 경우가 많다. 재전송이 많이 발생하면, 또다시 congestion을 일으켜 결국 돌아올 수 없는 강을 건너버릴 것이다.
따라서 이러한 불상사가 생기지 않도록 congestion이 발생할 것 같으면 미리미리 대처하는 것이 필요하다.
그에 앞서 여러가지 시나리오를 보며 전체적인 congestion에 대한 개념을 잡아보도록 하자.
2. Case of congestion
1) 라우터의 queue가 무한이며, 재전송이 발생하지 않는 경우
첫번째 시나리오는 패킷을 전송하는 라우터의 queue의 용량이 무한인 경우이다. 또한, delay로 인한 재전송이 발생하지 않는 경우를 가정하였다. 물론 이러한 경우는 실제 네트워크 환경에서 존재하지 않는 이상적인 환경이다.
라우터에서 빠져나가는 output link의 capacity가 R 이라고 가정했을 때, 측정되는 throughput과 delay는 다음과 같다.
이처럼 라우터의 queue가 무한이며, 재전송이 발생하지 않는 경우, input link와 output link는 R/2까지 linear하게 증가하며 이후부터는 R/2로 유지된다.
delay는 천천히 증가하다가 input link가 R/2에 가까울 경우 급격히 증가하는 것을 알 수 있다.
2) 라우터의 queue가 무한하지 않으며, 패킷 loss로 인한 재전송이 발생하는 경우
두번째 시나리오는 라우터의 queue가 무한하지 않으므로 패킷 loss가 발생하며, 이로인한 재전송이 발생하는 경우이다. 이 시나리오는 실제상황과 거의 비슷하지만, delay로 인한 재전송은 고려하지 않은 경우이다.
위의 그림에서 알 수 있듯이 재전송이 발생하므로 application layer에서 생성된 데이터보다 transport layer에서 전송된 패킷의 양이 더 많다. 또한, 중간에 패킷들이 loss될 수 있으므로 receiver이 받는 패킷의 양보다 sender가 보내는 패킷의 양이 더 많다.
하지만, delay로 인한 재전송은 고려하지 않았으므로 receiver 측의 application layer와 transport layer에서의 데이터 양은 동일하다. 이러한 상황을 수식으로 나타내보면 아래와 같다.
3. 라우터의 queue가 무한하지 않으며, 패킷 loss + 패킷 delay로 인한 재전송이 발생하는 경우
세번째 시나리오가 실제 환경과 거의 유사한 환경이다. 라우터의 queue가 무한하지 않으며, 패킷 loss나 패킷 delay로 인한 재전송이 모두 발생하는 경우이다.
다른 부분은 시나리오2와 유사하지만, 패킷 delay로 인해 발생한 재전송을 고려해야 하므로, receiver측의 transport layer에서 받는 데이터 양이 application layer에서 받는 데이터의 양보다 많다.
왜냐하면 실제로 패킷이 정상적으로 받았음에도 delay로 인해 receiver의 transport layer로 한번 더 오기 때문이다.
이러한 상황을 수식으로 나타내보면 아래와 같다.
3. congestion control
앞서 어떤 상황에서 congestion이 발생하는지 시나리오별로 살펴보았다. 그렇다면 어떻게 congestion을 control하는지 개략적으로 살펴보자.
- End-to-end congestion control
이 방식은 transport layer에서 congestion을 처리하는 방식이다. 사실 congestion은 실제 패킷들이 전송되는 network layer에서 발생한다. 하지만, 각각의 layer들은 독립적으로 동작하기 때문에 다른 layer의 상황을 알 수 없다.
따라서 transport layer에서는 network layer에서의 피드백 없이, 패킷들이 전송되는 상황을 보고 congestion이 발생할 것을 추측하여 congestion control을 진행한다.
이 방식은 transport layer에서 congestion control을 처리할 수 있다는 장점이 있지만, 정확하게 상황을 보고 처리하는 것이 아니기 떄문에 정확도가 떨어진다는 단점이 존재한다.
- Network-assisted congestion control
이 방식은 network layer에서 직접 congestion을 처리하는 방식이다. 실제 패킷 전송을 담당하는 network layer의 라우터들이 직접적으로 피드백을 주고, 이를 바탕으로 congestion control을 진행한다.
라우터들은 congestion을 기록하기 위해 (SNA, DECbit, ECN, ATM) 등과 같은 방식을 사용하거나, 직접적으로 현재 전송 rate를 기록하여 처리한는 방법이 존재한다.
이 방식은 직접적으로 라우터가 보고 congestion을 처리하는 것이므로 정확하다는 장점이 있지만, 여러가지 구현상 문제로 실질적으로 널리 사용되는 방법은 아니다.
4. 무선 네트워크에서의 고려사항
지금까지 살펴본 상황은 모두 유선 네트워크 상황이다.
따라서 라우터의 queue에서 패킷이 loss 되거나, delay되어 재전송이 되는 경우만 생각해보았다.
하지만, 실제 환경에서는 무선 네트워크도 널리 사용되므로 이 과정에서 패킷이 loss되는 케이스도 충분히 고려해보아야 한다.
오늘 배운 내용을 정리해보면,
1. 패킷들이 전송되는 과정에서 loss 나 delay가 발생하며 congestion이 발생한다.
2. congestion을 방지하기 위해 congestion control 을 사용해야 한다.
위 내용은 공부하며 작성한 것으로 오류가 있을 수 있습니다.