9-1:Principles of Congestion Control

congestion control이 왜 필요하냐면

• 큐잉 딜레이
• 패킷 로스

위 두가지가 congestion 유발

 

라우터에 교환을 위한 버퍼가 있는데, 이 버퍼는 항상 유한한 크기를 가니다.

그리고 앞에서 배웠던 것 처럼

큐잉 딜레이는 트래픽 레이트가 1에 가까워질 수록 기하급수적으로 증가한다.

이렇게 딜레이가 증가하면, 통신을 제대로 할 수가 없으니 congestion control 이 필요한 것이고,

 

버퍼가 가득 차면, 패킷을 잃어버릴 수 있기 때문에, congestion control이 필요한다.

 

여기서 이제 앞으로 나오는 주요 용어는

1) congestion control

2) throughput (처리량)

3) capacity (라우터와 호스트 사이에서 수용할 수 있는 최대 양)

4) λin, λout (데이터 보내는 전송량, 데이터 받는 전송량)

5) 홉 (각 호스트사이의 라우터)

 

시나리오 1️⃣: 라우터 버퍼가 무한대 ♾

이렇게 되면 각각 전송하는데 최대 R(라우터 capacity)씩 사용해서 보내고 받고 할 수 있다.

그래서 λin 높아져도 R를 넘을 수는 없다.

 

라우터는 무한한 버퍼를 가지고 있으므로, 딜레이는 있을 수 있지만, data loss는 일어나지 않는다. 

언젠가는 모든 데이터가 도착한다. 그렇지만 R에 가까워질수록 버퍼가 차면서 딜레아가 급격히 증가한다.

 

그래서 λin이 R만큼증가할 때는 λin이 증가하는 만큼늘어나지만,

R이 되면 그이상 증가하지 않는다.

 

 

위 그림과 같은 상황이면 R을 두개의 호스트가 나눠쓰기 때문에 한 호스트당 capacity가 R/2가 된다.

λin는 R/2를 넘을 수 없다.

 

위 그림에서 보는 것과 같이

λin이 R/2에 가까워질 수록 딜레이시간이 기하급수적으로 증가한다 (큐잉 딜레이 1)

 

시나리오 2️⃣: 라우터 버퍼가 유한

시나리오 2️⃣- ①: 버퍼가 가득찰 수 있고, 이때문에 loss가 일어남을 센더는 바로 알 수 있다는 가정

이러한 상황에서 transport layer에서는  λ'in는 λin의원래 데이터 전송과 재전송을 모두커버한다.

 

그리고 이렇게 패킷드랍의 가능성이 있으므로 이만큼의 throughput 효율성이 떨어진다.

 

버퍼가 가득 찼을 때(λin ~= R/2)재전송을 위한패킷들때문에 떨어지는 효율성

 

시나리오 2️⃣- ②: 버퍼가 가득찰 수 있고, loss가 일어남을 센더를 timeout을 통해서만 알 수 있음-> 패킷 중복 가능성

 

 이러한 상황에서는 불필요한 재전송이 발생할 가능성이 있다.

빠른 타임아웃은 더 많은 중복을 야기한다.

중복으로 받은 데이터는 처음 것을 받고 다음에 온 것은 무시한다.

 

재전송이 불필요한 패킷들을 재전송함하기 때문에  2️⃣- ①보다 더 효율이 떨어진다.

위 표와 같이 해당 불필요한 재전송에 의해 효율이 더 떨어진다.

 

시나리오 3️⃣: 라우터 버퍼가 유한 + 멀티 홉

그림과 같이 하나의 호스트로 가는데 라우터(홉)을 여러개 거쳐서 가는 것을 멀티 홉이라고 한다ㅏ.

 

화살표를 따라 각 호스트들끼리 지금 데이터를 전송하고 있다.

그러면 어플리케이션 레이어들에서 λin 정도 들었던 것들을, 트랜스미션 레이어에서 재전송까지 해야하니까 λ'in= λin+재전송데이터

근데 이 λ'in와 λin가계속해서 증가한다면,라우터를 공유중이므로,

하나가 많이 차지하려할 수록 다른 공유중인 애들한테 영향을 준다.

이와 같이 혼잡해지면, 공유중인 다른애들 버퍼 차지량이 떨어진다.

이렇게 다른 애들의 버퍼 차지량이 떨어지면서, 해당 throughput이 0에 수렴할 수 있다.

 

이렇게 공유중인 다른 애가 이 공유중인 라우터에서 드랍될 수 있는데, 이렇게 드랍된다면

이애가 지금까지 이 라우터까지 오느라 거쳤던 모든 자원들을 낭비하는 것과 마찬가지이다.



위의 예시와 같이 이런 상황에서 서로 영향을 주게 된다.

그렇기 때문에 해당 throughput을 예측할 수 없게 되어 아래 표와 같은 표가 나오는 것이다.

정리

정리하자면,

- throughput은 capacity를 넘어갈 수 없다.

- throughput이 capacity에 가까워질 수록 딜레이가 늘어난다.

- 모든 로스/재전송은 의미있는 throughput을 감소시킨다.

- 의미없는 로스/재전송은 의미있는 throughput을 더 감소시킨다.

- 멀티홉에서 서로의 전송률에 영향을 준다

- 다른 애때문에 전송중인 데이터가 드랍된다면 그간의 자원 낭비로 이어진다.

 

이런 congesion을 control하기 위한 2가지 접근 방법이 있다.

1️⃣End-end congestion control

종단 간에만 혼잡도를 컨알고 컨트롤하는 것 (flow control과 비슷)

종단 간의 정보만 활용함으로 중간 네트워크 정보를 알지 못한 상태로 "예측"한다.

이 예측은 loss,delay 내용을 활용하여 예측한다.

- TCP

 

2️⃣Network-assisted congestion control

라우터가 도와주는 것

라우터가 피드백을 제공해준다. 호스트들 사이에 있는 라우터 중에

congestio이 발생한 라우터가 피드백을 제공한다.

그리고 피드백 제공하는 방법으로는

congestion level을 알려주거나,

직접 sending rate을 설정할 수 있다.

- TCP ECN, ATM, ..