이 포스팅은 [Computer Networking: A Top-Down Approach]을 바탕으로 작성되었습니다.
열심히 공부하고 올리는 포스팅이지만... 저는 그저 말하는 감자이므로 정확하지 않은 내용도 포함될 수도 있습니다..
flow control이란?
지난 포스팅에서 말했듯이 receiver가 받을 수 있는 최대 양을 명시함으로써 sender가 전송 속도를 조절하는 것이다.
이와 비슷하면서 다른 개념으로 congestion control이 있다.
congestion은 '혼잡'이라는 뜻이다. 네트워크에서는 이 혼잡은 '여러 sender가 패킷을 빠르게 전송 네트워크 제어가 어려운 상황'을 뜻한다. congestion으로 인해 queing daley와 packet loss가 발생한다.
flow control과 congestion control을 잘 구분할 줄 알아야한다.
| flow control | congestion control |
| 네트워크와 관련이 없다 | 네트워크와 관련이 있다 |
| 하나의 sender | 여러 sender |
scenario1 :
하나의 라우터만 존재하고 라우터의 버퍼는 무한하다.
두 개의 flow가 있다. (flow = 데이터 전송)
link capacity는 R이다.
->
버퍼가 유한하므로 loss가 발생하지 않는다. loss가 발생하지 않으므로 재전송이 필요하지 않다.
하지만 queing delay가 무한대로 증가한다.
두 flow의 sending rate의 합이 R을 초과하면 congestion이 발생한다.
scenario2 :
하나의 라우터만 존재하고 라우터의 버퍼는 유한하다.
scenario2 - 1 : perfect knowledge
버퍼에 자리가 있을 때에만 패킷이 전송된다. 그러므로 loss가 발생하지 않는다.
scenario2 - 2 : some perfect knowledge
sender는 패킷이 언제 drop되었는지 알 수 있다.
재전송으로 인해 처리량이 감소한다.
이로인해서 전송하는 쪽의 throughput > 받는 쪽의 throughput 이 된다.
loss로 인해 재전송이 필요하기 때문에 처리량이 증가한다.
scenario2 - 3 : un-needed duplicates
loss가 발생하는 경우는 두 가지 이다.
1. 실제로 loss가 발생한 경우
2. 가짜로 loss가 발생한 경우 (premature timeout)
가짜 loss로 인해 재전송이 추가적으로 필요하기 때문에 2-2 보다 더 처리량이 감소한다.
2-2와 동일하게 전송하는 쪽의 throughput > 받는 쪽의 throughput 이 된다.
loss로 인해 재전송이 필요하기 때문에 처리량이 증가한다.
scenario3 :
4개의 sender 존재
->
A의 red flow와 B의 blue flow 가 하나의 link를 공유하고 있다.
이때! red flow의 sending rate를 증가시키면 어떻게 될까? (congestion)
blue flow의 패킷은 모두 drop된다. 즉, red flow가 link를 독점하는 것이다.
이를 통해 알 수 있는 사실은 flow의 경로 스위치 중 한 곳이라도 congestion이 발생하면 loss가 발생한다는 것이다.