혼잡제어의 관리(Congestion Control)
전에는 네트워크가 혼잡해짐에 따라 라우터 버퍼들의 오버플로우로부터 발생하는 손실에 대해 알아봤다. 이는 네트워크혼잡(특정한 트랜스포트 계층 세그먼트의 손실)의 증상은 다루지만, 네트워크 혼잡 원인(높은 전송률로 데이터를 전송하려는 너무나 많은 출발지)을 다루지 않는다. 이를 처리하기 위해 네트워크 혼잡을 일으키는 송신자를 억제하는 메커니즘이 필요하다.
혼잡의 원인과 비용
Scenario 1: 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터
호스트 A의 애플리케이션이 λin바이트/초의 평균 전송률로 연결에 데이터를 보내고 있다고 가정하자. 첫 번째 시나리오에서 호스트 A가 라우터에게 제공하는 속도는 λin바이트/초이다. 호스트 B도 비슷한 방법으로 동작하며, λin바이트/초의 전송률로 많은 데이터를 전송한다고 가정하자. 용량 R의 공유 출력 링크상으로 전달되는데 A, B가 동시에 쓰므로 R/2까지 처리될 수 있다.
연결당 처리랑(per-connection throughput: 수신자 측에서의 초당 바이트 수)은 0과 R/2 사이에서 송신자의 전송률과 같다. 하지만 전송률이 R/2 이상일 때, 처리량은 단지 R/2이다. 처리량에서 이러한 상위 제한은 두 연결 사이에서 링크 용량 공유의 결과이다. 오른쪽 그래프를 보면 전송률이 R/2에 근접했을 때 평균 지연이 점점 커짐을 확인할 수 있다.
Scenario 2: 2개의 송신자, 유한 버퍼를 가진 하나의 라우터
유한 버퍼란 이미 버퍼가 가득 찼을 때 도착하는 패킷들이 버려진다는 것을 의미한다. 또한 각 연결은 신뢰적이라고 가정한다. 트랜스포트 계층 세그먼트를 포함하는 패킷이 라우터에서 버려지면, 결국 송신자에 의해 재전송될 것이다. 애플리케이션이 원래의 데이터를 소켓으로 보내는 송신율을 λin바이트/초로 표시하자. 네트워크 안으로 세그먼트를 송신하는 트랜스포트 계층에서의 송신율은 λ'in바이트/초로 표시하고 이는 네트워크에 제공된 부하라고 부른다.
패킷이 확실히 손실된 것을 알았을 때만 송신자가 재전송하는 경우를 생각해 보자. 이런 경우 성능은 조금 떨어지게 된다.
송신자에서 너무 일찍 타임아웃되는 바람에 패킷이 손실되지 않았지만 큐에서 지연되고 있는 패킷을 재전송하고 있는 경우를 생각해 보자. 이 경우 원래의 데이터 패킷과 재전송 패킷 둘 다 수신자에게 도착한다. 물론 수신자는 단지 하나의 패킷 복사본만 필요하므로 재전송된 패킷은 버린다. 따라서 여기에 혼잡 네트워크의 또 다른 비용이 생긴다.
Scenario 3: 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로
트래픽이 많은 경우 A~C 종단간 처리율이 0이 된다는 것을 의미한다. 따라서 제공된 부하와 처리량 간의 트레이드오프(tradeoff)가 발생한다.