본문 바로가기

network

[컴퓨터 네트워킹]3장 트랜스포트 계층 - 3

3장 트랜스포트 계층

3.7 TCP 혼잡제어

TCP의 혼잡 제어 방법

-> TCP가 취한 접근방법은 네트워크 혼잡에 따라 연결에 트래픽을 보내는 전송률을 각 송신자가 제한하도록 하는 것

 

송신자 전송 트래픽을 어떻게 제한하는가?

혼잡 윈도우(congestion window : cwnd) : TCP 송신자가 네트워크로 트래픽을 전송할 수 있는 비율을 제한하도록 한다.

 

송신 쪽 확인 응답이 안 된 데이터의 양(LastByteSent - LastByteAcked) <= min{ cwnd, rwnd }

 

경로의 혼잡을 어떻게 감지?

CASE 1

타임아웃 또는 수신자로부터 3개의 종복된 ACK 수신 발생 -> 네트워크가 혼잡함을 의미 -> 송신자의 전송률을 제한

 

CASE 2

정상적인 ACK 수신 -> 네트워크가 원할함을 의미 -> 송신자의 전송률 증가

 

전송률 증가 폭은 ACK의 도착 속도로 조절한다.

- 확인응답이 빠른 속도로 도착 -> 혼잡 윈도우 빨리 증가

- 확인응답이 느린 속도로 도착 -> 혼잡 윈도우 느리게 증가

==> 이 같은 작업을 자체 클로킹(self-clocking)이라고 한다.

 

송신율을 변화시키기 위해서 어떤 알고리즘을 사용?

슬로 스타트 (slow start) - 필수

혼잡 윈도우 크기를 적은 값부터 시작해서 확인 응답을 받을 때마다 지수적으로 증가시키는 것

 

INIT

초기 혼잡 윈도우 값 : 1MSS => 초기 전송 속도 1MSS/RTT

 

CASE 혼잡 x

-> 해당 전송 속도로 모든 세그먼트가 확인 응답이 된다면 혼잡 윈도우 값을 2배씩 증가시킴

(각 확인응답 세그먼트에 대해 하나의 MSS만큼 혼잡 윈도우 증가)

 

CASE 혼잡(타임아웃 발생시)

-> 혼잡 윈도우의 값을 다시 1MSS로 설정, ssthresh(slow start threshold, 슬로 스타트 임계치의 약자) 상태 변수 값을 cwnd/2 로 설정


CASE 혼잡(3개의 중복 ACK)

-> 빠른 회복 상태로 진입

 

CASE ssthresh == cwnd (슬스 스타트 임계치가 혼잡 윈도우 값과 같을 때)

-> 혼잡 회피 모드로 전환

 

혼잡 회피 (congestion avoidance) - 필수

INIT

슬로 스타트 상태에서 변경되었므로 혼잡 윈도우 값은 혼잡이 마지막으로 발견된 시점의 혼잡 윈도우 값의 절반이다.

 

CASE 혼잡 x

RTT당 1MSS만큼 혼잡 윈도우 증가

 

CASE 혼잡(타임아웃 발생시)

-> 혼잡 윈도우의 값을 다시 1MSS로 설정, ssthresh(slow start threshold, 슬로 스타트 임계치의 약자) 상태 변수 값을 cwnd/2 로 설정 -> slow start 상태로 전환

 

CASE 혼잡(3개의 중복 ACK)

-> cwnd의 값을 반으로 하고 ssthresh값을 3개의 중복 ACK를 수신한 시점에서의 cwnd 값의 반으로 한다.

-> 빠른 회복 상태로 전환

 

빠른 회복 (fast recovery) - 권고

 

CASE 혼잡 x

-> 혼잡 윈도우 값을 ssthresh 값으로 초기화 -> 혼잡 회피 상태로 전환

 

CASE 혼잡(타임아웃 발생시)

-> 혼잡 윈도우의 값을 다시 1MSS로 설정, ssthresh(slow start threshold, 슬로 스타트 임계치의 약자) 상태 변수 값을 cwnd/2 로 설정 -> slow start 상태로 전환

 

CASE 혼잡(중복 ACK)

-> 혼잡 윈도우 값 RTT당 1MSS 씩 증가

TCP 혼잡제어의 FSM 설명

+mss (max segment size)

+FSM (finite state machine)

+cwnd (congestion window)

 

TCP 처리율의 거시적 설명

+슬로우 스타트 상태는 지수적으로 빠르게 단계를 벗어나므로 무시

+손실 이벤트가 발생할 당시의 혼잡 윈도우 값 W라 표시

 

TCP 전송률 범위 = ( W/2*RTT, W/RTT )

 

전송률은 선형적으로 증가하므로 TCP 연결의 평균 처리율 = 0.75*W/RTT 이다.

 

3.7.1 공평성

TCP 연결 1과 2에 의해 실현된 처리율

+ 두 연결이 같은 MSS와 RTT를 갖는다

+ 어떠한 다른 TCP 연결이나, UDP 데이터그램도 이 공유된 링크를 통과하지 않음

+ 슬로우 스타트 현상 무시

 

혼잡 회피 방식에서 45도 각도로 선형적으로 혼잡 윈도우가 증가한다.

네트워크가 혼잡할 때 혼잡 윈도우는 반토막 나는데 이는 원점과 혼잡 감지시 처리율의 중간값으로 이동한다.

이와 같은 것을 반복하면 그림과 같이 이상적인 처리율에 가까워진다.

 

공평성과 UDP

1. 멀티미디어 애플리케이션들은 TCP를 사용하지 않음

- 혼잡제어로 인한 전송 속도 조정을 하지 않음

 

2. UDP 사용

- 일정한 속도로 오디오/비디오를 전송

- 패킷 손실 감수

 

3. TCP 관점에서 UDP는 공평하지 못함

- 다른 연결과 협력하지 않고, 전송률 조절도 하지 않음

- UDP가 TCP 트래픽을 밀어낼 가능성 있음

 

공평성과 병렬 TCP 연결

TCP 기반 애플리케이션이 두 호스트 사이에 다중 병렬 연결(한 애플리케이션에서 여러개의 TCP 연결을 사용) 될 수 있음

- 웹 브라우저는 웹 페이지에 다중 객체 전송을 위해 다중 병렬 TCP 연결 사용

 

ex) 9개의 진행중인 연결을 지원하는 전송률 R인 링크

- 새 애플리케이션이 1개의 TCP 연결을 사용 => 전송률 R/10 획득

- 새 애플리케이션이 11개의 병렬 TCP 연결을 사용 => 전송률 R/2 획득. 불공평한 할당

 

3.7.2 명시적 혼잡 표시(Explicit Congestion Notification, ECN): 네트워크-지원 혼잡제어

네트워크가 명시적으로 TCP 송신자와 수신자에게 혼잡을 알리는 IP와 TCP의 확장이 제안되고, 구현 및 구축되었다. 이러한 네트워크-지원 혼잡제어의 형식을 명시적 혼잡 표시(Explicit Congestion Notification, ECN)이라고 알려져 있다.

 

네트워크 계층에서는 IP 데이터 그램 헤더의 서비스 형식 필드 내에 두 비트가 ECN에 사용된다. 그 중 하나의 비트는 라우터에 의해 사용되는데 라우터가 경험하는 혼잡을 표시한다. 

-> ECN 혼잡 표시는 지속적인 혼잡의 경우에만 세팅되도록 권고

 

절차

1. 수신 호스트의 TCP가 수신된 데이터 그램을 통하여 ECN 혼잡 표시 수신

2. 수신 호스트의 TCP는 송신 호스트의 TCP에게 ECE(ECN Echo) 비트를 세팅함으로써 혼잡 표시 알림

3. 송신 TCP는 혼잡 윈도우를 반으로 줄임

4. 손실된 세그먼트에 대해 빠른 재전송으로 반응하는 것과 같이 다음 전송되는 송신자에서 수신자로 가는 TCP 세그먼트 헤더에 있는 CWR(혼잡 윈도우 축소, Congestion Window Reduced) 비트를 세팅