Book/COMPUTER NETWORKING A TOP-DOWN-APPROACH

3.6 Principles of Congestion Control

S0LL 2024. 11. 24. 02:34

3.6.1 The Causes and the Costs of Congestion


 

 

네트워크 혼잡(congestion)은 데이터를 보내는 송신자가 많아지며 네트워크 용량을 초과할 때 발생한다.

이로 인해 패킷 손실, 지연 증가, 네트워크 성능 저하가 나타난다. 혼잡 문제를 해결하려면 혼잡의 원인과 그로 인한 비용을 이해해야 한다.

 

혼잡의 원인과 결과를 이해하기 위한 3가지 시나리오

 

Scenario 1: Two Senders, a Router with Infinite Buffers

 

환경: Host A와 Host B가 동일한 라우터와 단일 홉 링크를 공유한다. 라우터의 버퍼는 무한하다고 가정한다.

상황 설명:

두 호스트가 동일한 전송률()로 데이터를 전송하며, 공유 링크의 용량은 이다.

링크 용량을 초과하는 데이터는 라우터 버퍼에 쌓인다.

결과:

1. 각 연결의 Throughput(처리율): 송신률이 를 초과하면 처리율은 로 제한된다.

2. Delay(지연): 송신률이 에 접근할수록 지연이 급격히 증가한다.

3. Figure 3.43 Figure 3.44:

처리율은 에서 포화된다.

지연은 송신률이 에 가까워질수록 기하급수적으로 증가한다.

결론:

큰 지연은 혼잡 네트워크의 주요 비용 중 하나이다.

처리율 측면에서는 이상적일 수 있지만, 지연이 과도하게 커질 경우 네트워크 성능에 심각한 영향을 준다.

 

Scenario 2: Two Senders and a Router with Finite Buffers

 

환경: 시나리오 1과 동일하나, 이번에는 라우터 버퍼가 유한하다.

상황 설명:

데이터가 라우터에 도착했을 때 버퍼가 가득 차 있다면, 패킷이 손실된다.

손실된 데이터는 송신자에 의해 재전송된다.

결과:

1. 손실 및 재전송:

패킷 손실이 발생하면, 재전송으로 인해 네트워크 부하가 증가한다.

결과적으로 실제 처리율이 감소한다.

2. Figure 3.46:

재전송 없는 경우: 처리율은 송신률 와 동일하다.

재전송 포함: 처리율은 감소하며 또는 에 가까워진다.

비효율적인 재전송으로 인해 자원이 낭비된다.

결론:

혼잡 상태에서 버퍼 오버플로가 발생하면, 재전송이 혼잡을 더 악화시킨다.

재전송된 데이터가 라우터를 반복적으로 점유하며 대역폭을 낭비한다.

 

Scenario 3: Four Senders, Routers with Finite Buffers, and Multihop Paths

 

환경: 여러 송신자(Host A, B, C, D)가 서로 다른 경로를 따라 다중 홉을 통해 데이터를 전송한다.

상황 설명:

공유된 라우터(R1, R2, R3, R4)는 서로 다른 링크 용량 을 갖는다.

각 링크의 버퍼가 제한적이기 때문에 데이터가 손실될 가능성이 크다.

결과:

1. 경쟁과 손실:

경로 간 경쟁으로 특정 링크(R2)에서 데이터 손실이 발생한다.

A-C 연결의 처리율은 감소하고, 손실된 데이터를 재전송하는 과정에서 자원이 낭비된다.

2. Figure 3.48:

처리율이 의 증가에 따라 증가하다가, 혼잡 상태에서 급격히 감소한다.

3. 낭비된 작업:

혼잡으로 인해 일부 패킷은 라우터에서 드롭된다.

이미 업스트림 라우터가 처리한 데이터가 낭비되는 상황이 발생한다.

결론:

혼잡 상태에서 데이터 손실은 네트워크 전체 성능을 악화시킨다.

패킷이 전송 중간에 드롭되면, 네트워크 자원 활용 효율성이 떨어진다.

 

혼잡으로 인한 비용

 

1. 지연 증가:

송신률이 링크 용량에 가까워질수록 큐 대기 시간이 급증한다.

2. 패킷 손실:

제한된 버퍼로 인해 데이터가 손실된다.

3. 재전송 증가:

손실된 데이터를 재전송하면 네트워크 부하가 가중된다.

4. 낭비된 작업:

전송 중간에 드롭된 패킷으로 인해 이미 소비된 네트워크 자원이 낭비된다.

 

결론

 

혼잡은 네트워크 성능에 큰 영향을 미치는 주요 문제이다. 혼잡 상태에서 네트워크 자원의 낭비를 줄이고, 지연과 손실을 최소화하기 위한 효과적인 혼잡 제어 메커니즘이 필요하다.


3.6.2 Approaches to Congestion Control


 

네트워크 혼잡 제어에는 두 가지 주요 접근 방식이 있다.

이는 네트워크 계층이 전송 계층에 혼잡 제어를 명시적으로 지원하는지 여부에 따라 구분된다.

 

1. End-to-End Congestion Control

 

개념:

네트워크 계층이 혼잡 제어를 지원하지 않는다.

전송 계층은 네트워크의 상태를 암시적으로 파악하여 혼잡 제어를 수행한다.

작동 방식:

송신자는 패킷 손실(타임아웃이나 중복 ACK 수신)과 지연 증가와 같은 네트워크 동작을 관찰하여 혼잡 상태를 추정한다.

TCP는 이런 접근 방식을 채택하며, 네트워크 계층(IP 계층)에서 별도의 혼잡 피드백을 제공하지 않는다.

장점:

네트워크 계층에 의존하지 않고 전송 계층만으로 혼잡을 관리할 수 있다.

단점:

혼잡 상황에 대한 정확한 정보를 얻기 어려워 반응이 느릴 수 있다.

 

2. Network-Assisted Congestion Control

 

개념:

네트워크 계층(라우터)이 송신자와 수신자에게 혼잡 상태를 명시적으로 피드백한다.

피드백은 간단한 비트 플래그부터 최대 송신 속도 정보까지 다양하다.

예시:

ATM Available Bit Rate (ABR): 라우터가 지원 가능한 최대 전송 속도를 송신자에게 알린다.

DECbit, Explicit Congestion Notification (ECN): 네트워크 혼잡 상태를 나타내는 플래그를 패킷에 설정한다.

작동 방식:

네트워크 혼잡 상태를 송신자에게 알리는 두 가지 방법이 있다.

1. Direct Feedback: 라우터가 직접 송신자에게 피드백을 전송한다(예: choke 패킷).

2. Marked Packet Feedback: 패킷의 필드를 수정해 혼잡 상태를 표시한다. 수신자가 이를 송신자에게 알린다.

Figure 3.49:

Direct Network Feedback: 라우터가 송신자에게 직접 피드백을 보낸다.

Network Feedback via Receiver: 패킷이 수신자를 통해 송신자에게 혼잡 상태를 알린다.

장점:

정확한 혼잡 상태 정보를 송신자에게 제공한다.

혼잡에 빠르게 반응할 수 있다.

단점:

네트워크 계층과 전송 계층 간의 협력이 필요하여 구현이 복잡하다.

Figure 3.49: Two Feedback Pathways for Congestion

 

Figure 3.49는 네트워크가 송신자에게 혼잡 정보를 전달하는 두 가지 주요 경로를 보여준다.

1. Direct Network Feedback:

라우터가 직접 송신자에게 피드백(예: choke 메시지)을 보낸다.

송신자는 라우터로부터 혼잡 상태를 즉각적으로 알 수 있다.

2. Network Feedback via Receiver:

라우터가 패킷에 혼잡 정보를 표시하고, 수신자가 이를 송신자에게 전달한다.

이 방식은 추가적인 왕복 시간(RTT)이 소요될 수 있다.

 

결론

 

End-to-End Congestion Control은 네트워크 계층의 지원 없이 전송 계층에서 독립적으로 혼잡을 관리한다.

Network-Assisted Congestion Control은 네트워크 계층이 명시적인 피드백을 제공하여 보다 정교한 혼잡 관리를 가능하게 한다.

두 접근 방식 모두 특정 환경에 적합하며, TCP는 기본적으로 End-to-End 방식을 채택하지만, 일부 최신 구현에서는 Network-Assisted 방식을 병행하기도 한다.

'Book > COMPUTER NETWORKING A TOP-DOWN-APPROACH' 카테고리의 다른 글

4.1 An Overview of Network Layer  (2) 2024.12.03
3.7 TCP Congestion Control  (3) 2024.11.24
3.5 Connection-Oriented Transport: TCP  (0) 2024.11.24
CH3_Transport Layer  (2) 2024.10.19
CH2_Application Layer(2.5~2.7)  (3) 2024.10.19