[네트워크] 전송 계층(Transport) - TCP CUBIC ECN Fairness

Posted Dec 23, 2023

By Ennik 19 min read

전송 계층(Transport Layer)

TCP CUBIC

TCP CUBIC의 기본 개념

AIMD 대안
- TCP CUBIC은 AIMD 방식보다 더 효율적으로 대역폭을 탐사(probe)한다.
- 즉, 사용 가능한 대역폭을 찾아내어 네트워크의 전송률을 최적화하는 데 사용된다.
W_max
- 혼잡이 감지되었을 때의 전송률
- 네트워크의 병목 현상이 발생하기 전에 송신자가 도달한 최대 전송률
혼잡 상태 유지
- 혼잡이 감지된 후에는 송신률을 줄이지만, 네트워크의 병목 상태가 크게 변하지 않았다고 가정하고 W_max에 점차 근접한다.

TCP CUBIC의 그래프

CP CUBIC은 클래식한 TCP(AIMD)보다 더 빠르게 W_max에 접근한다.
CUBIC은 W_max에서 손실이 감지되면 전송률을 줄이고, 그 후에는 세제곱의 곡선을 따라 W_max로 다시 빠르게 증가시킨 다음, W_max에 가까워짐에 따라 증가 속도를 늦춘다.

TCP CUBIC의 동작

속도 조절: 패킷 손실이 감지되면 전송률을 절반으로 줄이고, 이후에는 W_max에 더 천천히 접근한다.
W 증가 함수: 전송률의 증가는 현재 시간과 K 지점 사이의 거리의 세제곱에 비례하여 결정된다.
여기서 K는 TCP 윈도우 크기가 W_max에 도달할 예상 시간이다.
K 조절 가능: K 값은 조절 가능하며, 이는 전송률 증가의 곡선을 조절할 수 있다는 것을 의미한다.

TCP CUBIC 정리

TCP CUBIC은 고속 네트워크 환경에서 더 빠르게 대역폭을 확보하고 혼잡을 효과적으로 관리하기 위해 설계되었다.
Linux 운영 체제에서는 TCP CUBIC이 기본 혼잡 제어 알고리즘으로 사용되며, 특히 고속 네트워크에서 더 나은 성능을 제공하는 것으로 알려져 있다.

Delay-based TCP congestion control

지연 기반 TCP 혼잡 제어의 주요 개념
- RTT_min: 네트워크 경로 상에서 관찰된 최소 RTT(Round-Trip Time), 즉 혼잡하지 않은 경로에 대한 RTT이다.
- 혼잡 윈도우 (cwnd) 및 처리량: 혼잡 윈도우는 RTT_min에 기반하여 계산된다. cwnd를 RTT_min으로 나눈 값은 혼잡하지 않을 때의 처리량으로 간주된다.
- 처리량 측정: 측정된 처리량은 마지막 RTT 간격에서 전송된 바이트 수를 RTT_measured로 나눈 값이다.
지연 기반 TCP 혼잡 제어의 동작 방식
- 송신자-수신자 파이프 관리: 송신자와 수신자 사이의 ‘파이프’를 적당히 채우되, 지연이나 버퍼링이 과도하게 발생하지 않도록 관리한다.
- 처리량 증가: 측정된 처리량이 혼잡하지 않은 경로의 처리량과 “매우 가깝다”고 판단되면, cwnd를 선형적으로 증가시킨다.
- 처리량 감소: 측정된 처리량이 혼잡하지 않은 경로의 처리량보다 “훨씬 아래”라면, cwnd를 선형적으로 감소시킨다.

BBR (Bottleneck Bandwidth and RTT)

BBR: Google의 내부 백본 네트워크에 배포된 지연 기반의 TCP 혼잡 제어 알고리즘
네트워크의 지연을 기반으로 하여 혼잡을 관리하고, 처리량을 최대화하며, 동시에 지연을 최소화한다.

Explicit congestion notification (ECN)

ECN은 네트워크의 혼잡 상태를 명시적으로 전송하는 메커니즘으로, TCP 통신에서 사용된다.
ECN의 주요 요소들은 다음과 같다.
- IP 헤더의 ToS 필드: ToS(Type of Service) 필드에 있는 두 비트는 네트워크 라우터에 의해 혼잡을 나타내기 위해 표시됩니다. 이 비트들은 네트워크 운영자에 의해 설정된 정책을 바탕으로 사용된다.
- 혼잡 표시 전달: 혼잡 표시는 목적지까지 전달되며, 목적지는 이 정보를 기반으로 혼잡 상태를 알 수 있다.
- ECE 비트: 목적지는 ACK 세그먼트에 ECE(Echo Congestion Experienced) 비트를 설정하여 송신자에게 혼잡 상태를 알린다.
- IP와 TCP의 결합: ECN은 IP 레벨(헤더의 ECN 비트 표시)과 TCP 레벨(TCP 헤더의 CE, Congestion Experienced, 비트 표시) 양쪽에서 동작한다.
ECN의 동작 방식:
- 소스 노드가 패킷을 전송할 때, ECN 가능한 경로에서는 IP 헤더 내의 ECN 비트가 설정되어 있을 수 있다.
- 네트워크 내의 혼잡을 감지한 라우터는 패킷의 ECN 필드를 변경하여 혼잡을 나타낸다.
- 이 패킷을 받은 목적지는 TCP ACK에 ECE 비트를 설정하여, 송신자에게 혼잡이 감지되었음을 알린다.
- 송신자는 이 정보를 받고 혼잡 제어 메커니즘을 통해 전송률을 조정한다.
ECN을 사용함으로써, 네트워크는 패킷 손실을 발생시키지 않고도 혼잡 상태를 송신자에게 알릴 수 있으며, 이를 통해 TCP 연결의 성능을 개선할 수 있다.
ECN은 특히 패킷 손실이 혼잡의 유일한 신호가 되는 것을 방지하기 위해 만들어졌다.

TCP fairness

TCP 공정성은 네트워크 리소스의 분배가 공평하게 이루어져야 한다는 개념이다.
만약 K개의 TCP 세션이 동일한 병목 링크를 공유하고 그 링크의 대역폭이 R이라면, 각 세션은 평균적으로 R/K의 비율로 대역폭을 사용해야 한다는 것이 공정성의 목표이다.

TCP 공정성의 이론

TCP는 공정한가?
- 이상적인 조건 하에서 TCP는 공정하다.
- 각 세션은 RTT(Round-Trip Time)가 같고 혼잡 회피 단계에 있는 고정된 수의 세션들만 존재할 때, 공정하게 대역폭을 공유할 수 있다.
Additive Increase
- TCP는 전송률을 선형적으로 증가시킨다. 즉, 각 세션은 전송률을 1씩 증가시킨다.
Multiplicative Decrease
- 손실이 감지될 때, TCP는 전송률을 비례적으로 감소시킨다.
- 각 세션은 대역폭의 절반으로 전송률을 줄인다.

공정성과 다른 프로토콜

UDP와 공정성
- 멀티미디어 애플리케이션과 같이 일부 앱은 TCP를 사용하지 않고 UDP를 사용한다.
- UDP는 혼잡 제어를 통해 전송률을 조절하지 않으며, 일정한 비율로 오디오나 비디오를 전송하고 패킷 손실을 감내한다.
인터넷의 공정성 감시
- 인터넷에는 혼잡 제어의 사용을 감시하는 ‘인터넷 경찰’이 없다.
- 애플리케이션 개발자나 사용자가 혼잡 제어 메커니즘을 적절히 사용할 책임이 있다.

공정성과 병렬 TCP 연결

병렬 TCP 연결
- 애플리케이션은 두 호스트 간에 여러 병렬 연결을 열 수 있다.
- 웹 브라우저가 이를 행하는 예로, 여러 연결을 통해 전체 대역폭의 큰 부분을 차지할 수 있다.
공정성의 문제
- 새로운 애플리케이션이 1개의 TCP 연결을 요청하면, 대역폭 R의 1/10을 얻게 된다.
- 하지만 같은 앱이 11개의 TCP 연결을 요청하면 R/2를 얻을 수 있으며, 이는 공정성의 원칙에 어긋날 수 있다.

QUIC: Quick UDP Internet Connections

QUIC (Quick UDP Internet Connections)는 구글에 의해 개발된 애플리케이션 계층 프로토콜이다.
기존의 TCP/IP 모델 위에 구축된 UDP를 기반으로 한다.
목표는 특히 HTTP의 성능을 향상시키는 것이다.
Chrome 브라우저와 모바일 YouTube 앱과 같은 많은 구글 서비스에 이미 구현되어 사용되고 있다.
QUIC의 주요 특징은 다음과 같다.

성능 향상: QUIC은 TCP 대신 UDP를 사용하여 연결의 설립과 끊김이 빠르고, 레이턴시가 낮다. TCP가 3-way handshake 과정을 거치는 반면, QUIC은 이를 최적화하여 더 빠른 연결 설정이 가능하다.
연결 설정(Connection Establishment): QUIC은 한 번의 RTT(Round-Trip Time)로 신뢰성, 혼잡 제어, 인증, 암호화 및 상태를 설정할 수 있다. 이는 TCP가 필요로 하는 여러 RTT와 대조된다.
에러 및 혼잡 제어(Error and Congestion Control): QUIC은 TCP의 손실 감지 및 혼잡 제어 알고리즘과 유사한 메커니즘을 채택한다. 이는 네트워크의 혼잡 상태를 감지하고 데이터 전송률을 조절하여 네트워크의 과부하를 방지한다.
다중 스트림 지원: QUIC은 여러 애플리케이션 수준 스트림을 단일 QUIC 연결 위에 중첩하여 멀티플렉싱을 지원한다. 이는 한 연결 내에서 독립적인 데이터 스트림이 가능하도록 하여, TCP에서 발생할 수 있는 헤드 오브 라인(HOL) 블로킹 문제를 해결한다.
보안: QUIC은 TLS(Transport Layer Security)를 기본적으로 사용하여 통신을 암호화하며, 이는 연결의 보안을 강화힌다.
실제 배포: QUIC은 Google 서버와 앱에서 널리 배포되어 사용되고 있으며, 특히 웹 서버에서는 기본 TCP 프로토콜로 자리잡고 있다.

QUIC은 특히 웹 트래픽과 같이 빠른 시작, 낮은 지연 시간, 멀티플렉싱이 필요한 환경에서 TCP의 대안으로 각광받고 있으며, 사용자 경험을 향상시키기 위한 웹 성능 최적화의 일환으로 개발되었다.

학교 시험 예상 문제

a) seq=k, data length=N bytes 인 segment 에 대한 ack number는?

b) Host A가 seq = NA, # of bytes = k인 segment를 시작으로 같은 크기의 segment 들을 이어서 6개를 보냈는데 세 번째 segment가 lost 되고 나머지는 모두 전송이 되었다고 할 때 Host A가 받는 ack numbers를 차례로 쓰시오(NA, k 사용)

NA+k, NA+2k, NA+2k, NA+2k, NA+2k

c) TCP의 flow control에서 수신자가 송신자의 전송을 일시 정지시키려면(freeze) 어떻게 해야 하는가?

Adwin = 0, (Recever’s window=0)으로 하여 송신자에게 보냄) 관련된 header의 필드는 무엇이며 그 값은 누가 제공하는가?

d) Cumulative ACK의 논리점 근거는 무엇이며 그로 인한 단점은?

근거: segment가 ack보다 데이터가 많아 ack를 잃었을 경우 손실이 크므로 ack를 lost하더라도 뒤의 ack로 그것을 보상할 수 있어 ack상실을 크게 낮출 수 있다.
단점: 하나의 세먼트가 lost된 경우 뒤의 세그먼트를 ack할 수 없다. 개별적인 세그먼트 손실에 빠른 대응이 어려움

4. 각각 2개의 host들을 연결하는 4개의 connection(Red, Blue, Green, Pink)들이 아래 그림 2와 같이 4개의 라우터 R1, R2, R3, R4에서 서로 만난다고 가정하자. 2개의 flow가 하나의 라우터에 들어올 때 출력에서의 대역폭 점유비율은 입력에서의 비율과 같다고 하자(통계적 다중화). 모든 링크의 대역폭은 1Mbps이고, 각 host가 모두 4Mbps씩 보낸다고 가정하자. Throughput은 sender가 보내는 대역폭이고 goodput은 receiver가 받는 대역폭이다. 라우터의 버퍼 크기는 무한대라고 가정한다.

a) 라우터 R1에 들어오는 두개의 flow A, B 의 대역폭이 각각 Ra = 4Mbps, Rb = r 이 라면, R1의 출력 링크로 나오는 flow A,B의 대역폭은 각각 얼마인가?

답) 4/(4+r), r/(4+r) Mbps

b) 위 a)에서 r 이라고 규정했지만, 4개의 라우터가 (입출력 flow들이 차지하는 대역폭 측면에서)같은 상황이라는 점을 고려할 때 r 의 값을 구할 수 있다. r 의 값을 구해 보시오. (반올림하여 소수점 이하 2째짜리까지 단위 Mbps).

답) 0.83Mbps, r = 4/(4+r), r= -2+2sqrt(2)

5. TCP fairness AIMD방식으로 CongWin을 조절하는 3개의 connection이 지금 각각 16kbytes(connection 1), 8kbytes(connection 2), 4kbytes(connection3)의 CongWin를 갖고 있다고 하자. 세개의 connection이 33kbytes/RTT의 대역폭을 가진 링크를 공유한다고 하고 다음 물음에 답하시오(세그먼트 크기는 1kbytes)

a) 처음으로 congestion이 일어나는 것 (CongWin가 congestion을 일으킬 정도로 커지는 것)은 몇 RTT 이후 인가?
- 답) 2RTT
b) 이후 CongWin을 줄인 후의 값은 각각 얼마인가?
- 답) 9 kbytes, 5 kbytes, 3 kbytes
c) 충분히 시간이 지난후 세 개의 connection 이 각각 가질 대역폭은?? (RTT = 100ms 가 정)
- 답) 모두 11kbytes/0.1sec =880kbps

6. RTT estimation: alpha = 0.25라고 가정하자(alpha는 이번 sample에 곱해지는 factor). 매번 RTT=200 ms로 고정되어 있는데, 한번 잘못 측정하여 400 ms로 측정하였다고 하자.

a) 현재의 RTT_estimate(n) = 200 ms이라면 다음 RTT_estimate(n+1)의 값은?(ms 단위)
- RTT_estimate(n+1) = (1-1/4)*200 + 1/4*400 = 250 ms
b) a)이후 계속되는 샘플들이 모두 200ms라 고 할 때 RTT_estimate(n+k)의 값을 나타내면?
- 200+50*(3/4)^(k-1)

0.2 네트워크

Network Transport Layer

This post is licensed under CC BY 4.0 by the author.