[네트워크] Chap 3.7 - Congestion이란?

Congestion이란?

Congestion이란?

너무 많은 source host들이 너무 많은 데이터를 빠르게 전송해서 라우터의 버퍼가 넘치는 상황을 말한다.

라우터의 버퍼가 넘치면, queueing delay가 발생하여 delay가 길어지고, packet이 loss되기도 한다.

 

flow control과 헷갈리지 말자!

flow control은 하나의 sender가 하나의 receiver에게 너무 빨리 보내버리는 것이고,

congestion control은 여러 sender가 데이터를 너무 빨리 보내버리는 것이다.

---

Principles of congestion control 

Congestion control

: too many sender가 데이터를 너무 빨리 보내는 상황을 control하여, 라우터의 버퍼가 넘치지 않도록 조절하는것!

 

rwnd가 없다고 가정하고, cwnd만을 고려하여 window size (W) = cwnd를 어떻게 조정하는지 알아보자.

---

Causes and costs of congestion at router buffer in the network

Congestion Control을 일으키는 요인

1. Link Bandwidth

2. Finite Buffer (at router)

3. Multi-hop paths

---

Cause/costs of Congestion : scenario 1

- 2 senders, 2 receivers

- 라우터의 버퍼는 infinite하다.

- 라우터의 input, output link의 capacity는 둘 다 R

- retransmission이 없다고 가정

즉 2 sender가 하나의 link를 공유하므로, 각자 최대 R/2까지 이용 가능하다.

버퍼가 무한하므로, R/2를 초과하게 input이 들어오더라도 계속 버퍼에 넣어둔다.

하지만 queueing delay는 무한히 발산하게 된다.

---

Cause/costs of Congestion : scenario 2

- 2 senders, 2 receivers

- 라우터의 버퍼 크기는 유한하다.

- sender는 retransmission 함

- Application layer에서 λin = λout

- Transport layer에서는 retransmission을 하므로 λ'in >= λin 

 

 

 

보내는 데이터의 양이 적을 때는 retransmission이 필요없으니 이상적인 y=x의 그래프와 비슷한 모양을 유지하지만,

R/2에 가까워질수록 일부 패킷이 재전송되기 시작하므로 capacity가 낭비된다.

=> 재전송되는 패킷이 있으므로, λ'in이 R/2일때 λout은 R/2보다 낮은 값이 된다.

 

---

Cause/costs of Congestion : scenario 3 (Multi-hop paths)

 

 

Data(A→C)와 Data(D→B)는 동일한 라우터의 버퍼를 공유
but, A는 동일 라우터까지 1-hop, D는 라우터로 2-hop이 걸림. 버퍼를 빨리 차지하는 A가 더 유리함  
but, 유한한 버퍼로 traffic이 쏟아짐 → A가 라우터 버퍼를 모두 차지하게 되어 Data(D→B) 트래픽은 해당 라우터에서 전부 drop된다. => Data(D→B)의 throughput은 0에 수렴

 

*congestion을 안하고 fixed cwnd를 쓰면 이렇다는 얘기*

D에서 B로 갈때 1번째 라우터를 지나, 그 다음 라우터(A랑 겹치는 라우터)에서 다 drop되기 때문에, 1번째 라우터로 가는 upstream 네트워크 resource가 낭비된다!

=> unneeded retransmissions at RT2 (1번째 라우터):  link carries multiple copies of pkt → decreasing goodput

 

λ_out = goodput  (receiver측에서 제대로 처음 1번 받은것만 count한 데이터 양)
λ'_in 증가에 따라 λ_out이 증가하다가, 어느 순간부터 loss와 retransmission이 발생함⇒ unneeded retransmissions, upstream transmission capacity was wasted

---

Two approaches towards congestion control

congestion control의 2가지 해결책을 알아보자.

network-assisted congestion control (①)

라우터가 도와주면 좋겠다는 방법
congestion이 어떻게 일어나는가에 대한 정보를 IP의 도움을 받음.
(예를 들면, congestion level을 설정하거나, sending rate를 설정한다.)
거의 사용하지 않는 방법
ex) TCP ECN

 

 

end-end congestion control (②)

no explicit feedback from network, 네트워크로부터 직접적인 피드백은 없다.
즉 라우터가 알려주는게 없다는 뜻!
따라서 관찰을 통해서 loss 또는 delay가 발생했다고 추측하는 방법이다.
=> 네트워크의 도움 없이도 송신자가 알 수 있는 방법!
TCP가 네트워크 상황을 추측 (timer, 3 duplicate ACK 등을 이용한다.)
=> RTT를 고려해 timeout을 조정한다.

다음 포스팅에서 이 방법에 대해 자세히 알아볼 것이다!

---

① Explicit Congestion Notification (ECN)

 

네트워크 라우터의 도움을 받아서 congestion이 발생했음을 표현하는 방법

 

IP header에 2bit를 이용하여 congestion이 일어났음을 표현한다.
=> 10이면 ECN 지원, congestion이 일어났다고 판단하면 ECN=11로 변경하여 보낸다.

이렇게 congestion이 일어났음을 표시한 header는, destination까지 전달된다.

=> 그러면 destination은 ECE bit를 1로 설정 → sender에게 congestion이 발생했다고 알려준다.

 

(중간에 있는 라우터들이 전부 다 도와줘야하기 때문에 성공적으로 쓰기는 어렵다. 그래서 잘 안쓰는 방법이다.)

 

---

② TCP congestion control Overview

segment가 timeout 또는 3 duplicated ACK으로 인하여 loss되면, network congestion이 발생한것

=> TCP의 sender rate를 줄인다 (congestion window size, cwnd 등)

 

이전의 unacked segment에 대한 ACK이 도착했다는건, congestion이 발생하지 않았다는 뜻

=> TCP의 sender rate를 증가

 

Goal : TCP senders don't congest the network but, at the same time make use of all the available bandwidth

=> available한걸 찾기 위해서 공격적으로 막 올려보내보다가, congestion이 발생했다고 판단되면 얼른 줄인다.

 

 

Congestion control의 목적

• to avoid congestion in the network by decreasing window size (cwnd)
• to achieve high link BW utilization by increasing window size (cwnd)