Chapter3: Transport Layer-2

흰제비갈매기 2024. 7. 4. 15:38

2024. 7. 4. 15:38

Connection-oriented transport: TCP

segment structure
reliable data transfer
flow control
connection management

TCP: overview

Point-to-Point
- 한 송신자와 한 수신자 간의 통신
- 일대일 연결

Reliable, In-Order Byte Stream
- 신뢰할 수 있고, 순서가 맞는 바이트 스트림 전송
- 메시지 경계 없음(연속된 바이트 스트림으로 처리)

Full Duplex Data
- 양방향 데이터 흐름을 지원
- 동일한 연결에서 동시에 송수신 가능
- MMS(Maximum Segment Size): 하나의 세그먼트에서 전송할 수 있는 최대 데이터 크기

Cumulative ACKs(Acknowledgements)
- 누적 확인 응답
- 특정 번호까지의 모든 패킷을 확인 응답하는 방식

Pipelining
- 여러 패킷을 동시에 전송하는 기술
- TCP 혼잡 제어 및 흐름 제어 메커니즘을 통해 윈도우 크기 설정

Connection-Oriented
- 연결 지향적 통신
- 데이터 교환 전에 제어 메시지를 주고받아 송신자와 수신자의 상태를 초기화하는 핸드셰이킹 과정 필요

Flow Controlled
- 흐름 제어
- 송신자가 수신자를 과부하시키지 않도록 전송 속도 조절

TCP segment structrue

Source Port #(출발지 포트 번호)
- 세그먼트를 송신하는 장치의 포트 번호

Dest Port #(목적지 포트 번호)
- 세그먼트를 수신하는 장치의 포트 번호이다.

Sequence Number(순서 번호)
- 바이트 스트림 내의 바이트에 순서를 매기는 데 사용된다. 이는 세그먼트의 첫 번째 바이트의 번호를 나타낸다.

Acknowledgement Number(확인 응답 번호)
- 송신자가 다음에 받을 것으로 기대하는 바이트의 순서 번호이다. 이 번호는 수신 측에서 데이터가 제대로 도착했음을 확인하는 역할을 한다.

Header Length
- TCP 헤더의 길이를 나타냅니다. 단위는 32비트 워드이다.

Flags
- 제어 비트로 구성되어 있으며, 각각의 비트는 특정한 제어 정보를 나타낸다.
  - C, E: 혼잡 알림(Congestion Nofitication)
  - U: 긴급 포인터(Urgent Pointer)
  - A: 확인 응답(ACK)
  - P: 푸시(Push)
  - R: 재설정(RST)
  - S: 동기화(SYN)
  - F: 종료(FIN)
Receive Window(수신 윈도우)
- 수신 측이 수신할 준비가 된 데이터의 최대 바이트 수를 나타낸다. 이는 흐름 제어에 사용된다.

Checksum(체크섬)
- 오류 검출을 위해 사용된다. 데이터와 헤더가 전송 중에 손상되지 않았는지 확인한다.

Urgent Data Pointer(긴급 데이터 포인터)
- 긴급 데이터의 끝을 가리키는 포인터이다. 긴급 데이터는 보통의 데이터보다 우선 처리된다.

Options(옵션, 가변 길이)
- 선택적 필드로, TCP 연결에 대한 추가 정보를 제공할 수 있다.

Application Data(응용 데이터, 가변 길이)
- 응용 프로그램에서 전송하는 실제 데이터

TCP sequence numbers, ACKS

Sequence numbers(순서 번호)

정의: TCP는 바이트 스트림을 전달할 때 각 바이트에 번호를 매긴다. 이 번호를 통해 송신 측과 수신 측은 각 바이트가 데이터 스트림 내에서 어디에 위치하는지 알 수 있다.
기능: 세그먼트의 첫 번째 바이트의 순서 번호를 지정하여 데이터의 정확한 순서를 유지하고 손실된 데이터를 재전송할 수 있게 한다.

Acknowledgements(확인 응답)

정의: 수신 측이 다음에 받을 것으로 기대되는 바이트의 순서 번호를 송신 측에 알려주는 메커니즘이다.
기능: 누적 ACK를 사용하여 현재까지 제대로 수신한 데이터의 마지막 바이트 다음에 올 바이트의 순서 번호를 송신 측에 알려준다. 이는 데이터의 손실이나 오류를 감지하고 재전송을 요청할 수 있게 한다.

중요한 질문 및 답변

Q: 수신 측이 순서가 뒤섞인 세그먼트를 어떻게 처리하는가?
A: TCP 사양은 이에 대해 명시적으로 규정하지 않으며, 구현자에게 맡겨진다.

TCP sequence numbers, ACKs

사용자가 'C'를 입력
- 호스트 A의 사용자가 문자 'C'를 입력
- 호스트 A는 이 데이터를 포함한 TCP 세그먼트를 생성
- 이 세그먼트의 순서 번호(seq)는 42, 확인 응답 번호(ACK)는 79, 데이터는 'C'이다.
- 이 세그먼트는 호스트 B로 전송된다.
호스트 B가 'C'를 수신하고 에코
- 호스트 B는 seq=42인 세그먼트를 수신한다.
- 호스트 B는 이 세그먼트를 확인 응답(ACK)한다. 확인 응답 번호(ACK)는 43이다.(다음에 기대되는 바이트의 순서 번호)
- 호스트 B는 데이터 'C'를 에코(반복)한다. 새로운 새그먼트를 생성하여 호스트 A로 보낸다.
- 이 세그먼트의 순서 번호(Seq)는 79, 확인 응답 번호(ACK)는 43, 데이터는 'C'이다.
호스트 A가 에코된 'C'를 수신
- 호스트 A는 Seq=79인 세그먼트를 수신
- 호스트 A는 이 세그먼트를 확인 응답(ACK)한다. 확인 응답 번호(ACK)는 80이다.(다음에 기대되는 바이트의 순서 번호)

TCP round trip time, timeout

Q. TCP timeout 값을 어떻게 설정할 것인가?

RTT보다 길어야 함: RTT(Round Trip Time)보다 길어야 한다. 그러나 RTT는 변동한다.
너무 짧은 경우: 타임아웃이 너무 짧으면 조기 타임아웃이 발생하여 불필요한 재전송이 일어날 수 있다.
너무 긴 경우: 타임아웃이 너무 길면 세그먼트 손실에 대한 반응이 느려질 수 있다.

Q. RTT를 어떻게 추정할 것인가?

SampleRTT: 세그먼트 전송 시점부터 ACK(확인 응답) 수신 시점까지의 시간을 측정한다
- 재전송된 세그먼트는 무시한다.
SampleRTT 변동: SampleRTT는 변동하기에, 추정된 RTT를 더 부드럽게 만들고 싶다.
- 최근 여러 측정값을 평균화하여 사용한다. 단순히 현재의 SampleRTT만을 사용하지 않는다.

스크린샷 2024-07-04 001104.png

12.6 kB

Exponential Weighted Moving Average(EWMA)
- 과거 샘플의 영향을 지수적으로 감소시킨다.
- 최신 SampleRTT에 더 많은 가중치를 두어, 네트워크 상태의 변동에 빠르게 반응할 수 있도록 한다.

이전 샘플의 영향 감소
- 오래된 SampleRTT의 영향력이 지수적으로 빠르게 감소하여, 최근의 네트워크 상태를 더 정확히 반영할 수 있다.

알파 값의 일반적 설정:
- α는 일반적으로 0.125로 설정됩니다. 이는 최근의 SampleRTT가 ExtimatedRTT에 어느 정도 영향을 미치는지를 결정한다.

타임 아웃 간격 설정

ExtimatedRTT: 예측된 RTT 값
DevRTT: SampleRTT가 EstimatedRTT로부터 벗어난 정도를 나타낸 값
Safety margin: 타임아웃 간격을 결정할 때 추가되는 여유 시간

타임아웃 간격을 예측된 RTT에 "안전 마진"을 더한 값입니다. 네트워크의 변동성을 고려하여, 타임 아웃 간격은 예측된 RTT와 DevRTT의 합으로 설정된다.

DevRTT 계산

β: 일반적으로 0.25로 설정되는 가중치
SampleRTT: 실제 측정된 RTT 값
EstimatedRTT: 예측된 RTT 값

DevRTT는 SampleRTT와 EstimatedRTT의 차이의 절대값을 사용하여 계산됩니다. 이는 예측된 RTT로부터의 편차를 측정하여, 타임아웃 간격 설정 시 변동성을 반영하는 데 사용된다.

TCP Sender(simplified)

event1: data received from application

세그먼트 생성: 수신한 데이터를 바탕으로 세그먼트를 생성한다
- 순번(seq #): 세그먼트 내 첫 번째 데이터 바이트의 바이트 스트림 번호이다.
타이머 시작: 타이머가 이미 실행 중이 아니라면 시작한다.
- 타이머는 가장 오래된 ACK되지 않은 세그먼트를 기준으로 생각한다.
- 만료 간격은 TimeOutInterval이다.

event2 : timeout 발생

segment 재전송: 타임아웃을 유발한 세그먼트를 재전송한다.
타이머 재시작: 타이머를 다시 시작한다.

event3 : ACK 수신

ACK 확인: 수신된 ACK가 이전에 ACK되지 않은 세그먼트를 확인하는 경우
- ACK 된 것으로 알려진 내용을 업데이트한다.
- ACK 되지 않은 세그먼트가 여전히 있는 경우 타이머를 시작한다.

TCP: retransmission scenarios

TCP fast retransmit

송신자가 동일한 데이터에 대해 3개의 추가 ACK(트리플 중복 ACK)를 수신하면, 송신자는 타임아웃을 기다리지 않고 확인되지 않은 세그먼트 중 가장 작은 순서 번호를 가진 세그먼트를 재전송한다.

TCP flow control

Q. What happens if network layer delivers data faster than application layer removes data from socket buffers

결과: 버퍼 오버 플로우

버퍼가 가득 차면 더 이상 데이터를 수용할 수 없게 되어, 추가로 도착하는 데이터는 손실된다.
이를 방지하기 위해 수신자는 송신자에게 윈도우 크기를 조정하도록 알려준다.
송신자는 수신자가 수용할 수 있는 데이터 양을 초과하지 않도록 조절한다. 송신자는 수신자의 버퍼가 넘치지 않도록 데이터를 너무 많이, 너무 빨리 전송하지 않는다.
TCP는 수신자의 현재 버퍼 상태를 기반으로 송신자가 보낼 수 있는 데이터 양을 제어한다.

주요 내용

수신자의 버퍼 공간 광고
- TCP 수신자는 자신의 여유 버퍼 공간을 TCP 헤더의 'rwnd(receive window)' 필드에 광고합니다.
- 'rwnd'는 수신자가 현재 수용할 수 있는 데이터의 양을 나타낸다.
RcvBuffer
- 'RcvBuffer'의 크기는 소켓 옵션을 통해 설정되며, 일반적으로 기본값은 4096 바이트이다.
- 많은 운영 체제는 'RcvBuffer' 크기를 자동으로 조정한다.
송신자의 데이터 전송 제약
- 송신자는 ACK되지 않은('unACKed') 데이터의 양을 수신한 'rwnd' 값에 맞춰 제한한다.
- 즉, 송신자는 'rwnd' 값보다 많은 데이터를 한 번에 전송하지 않는다.
버퍼 오버플로우 방지
- 이러한 메커니즘을 통해 수신자의 버퍼가 넘치는 상황을 방지한다.

TCP connection management

TCP 연결 관리는 데이터 교환 전에 송신자와 수신자가 연결을 설정하는 과정을 의미한다. 이를 위해 "handshake"라는 과정이 필요하며, 이는 연결을 설정하기 위한 절차이다.

연결 설정 동의
- 송신자와 수신자는 연결을 설정하는 데 동의한다. 이는 양쪽 모두가 연결을 설정하기를 원한다는 것을 알게 되는 과정이다.
연결 매개변수 합의
- 양쪽은 연결 매개변수(e.g. 시작 시퀀스 번호 등)에 대해 합의한다.

e.g.

왼쪽(client)
- 어플리케이션은 새로운 소켓을 생성하여 호스트 이름과 포트 번호를 지정
- e.g. Socket clientSocket = newSocket("hostname", "port number")
- 네트워크 계층을 통해 연결을 설정하며, 어플리케이션 계층에서 연결 상태와 연결 변수를 관리한다.

오른쪽(server)
- 서버는 소켓을 생성하여 연결을 수락한다.
- e.g. Socket connectionSocket = welcomeSocket.accept()
- 서버 역시 네트워크 계층을 통해 연결을 설정하며, 어플리케이션 계층에서 연결 상태와 연결 변수를 관리한다.

Agreeing to establish a connection

Q. will 2-way handshake는 항상 network에서 동작하는가?

문제점:

가변 지연(variable delays): 네트워크 환경에서는 메시지가 도착하는 시간이 일정하지 않는다. 지연 시간이 가변적이므로 연결 설정이 불안정할 수 있다.
메시지 재전송(retransmitted message): 메시지 손실로 인해 request 메시지를 재전송하는 경우가 발생한다.
메시지 순서 변경(message reordering): 네트워크에서는 메시지가 순서대로 도착하지 않을 수 있다. 순서가 뒤바뀌면 핸드 셰이크 과정이 실패할 수 있다.
상대방의 상태를 알 수 없음(cant see other side): 송신자는 수신자의 상태를 직접 확인할 수 없다. 상대방이 메시지를 받았는지 확인하는 방법이 없기에, 핸드셰이크 과정이 중단될 수 있다.

2-way handshake scenarios

clinet는 처음 x, server는 나중의 x, 그렇기에 client가 연결을 끊어도 server는 그대로 연결되어 있다. 이는 리소스 낭비

TCP 3-way handshake

클라이언트 측 상태

LISTEN
- 클라이언트 소켓이 연결 요청을 기다리는 상태
- 코드: 'clientSocket = socekt(AF_INET, SOCK_STREAM)(소켓 생성)
- 코드: 'clientSocket.connect((serverName, serverPort))'(연결 요청)

SYN_SENT
- 클라이언트가 초기 순서 번호(x)를 선택하고 SYN 메시지를 서버로 보낸 상태이다.
- 상태 전환: LISTEN -> SYN_SENT
- 메시지: 'SYNbit=1, Seq=x'(SYN 메시지)

ESTAB(Established)
- 클라이언트가 서버로부터 SYN-ACK 메시지를 받고, 이에 대한 ACK를 서버로 보낸 후 연결이 설정된 상태
- 상태 전환: SYN_SENT -> ESTAB
- 메시지: 'ACKbit=1, ACKnum =y + 1'(ACK 메시지)

서버 측 상태

LISTEN
- 서버 소켓이 연결 요청을 기다리는 상태
- 코드: 'serverSocket = socket(AF_INET, SOCK_STREAM)'(소켓 생성)
- 코드: 'serverSocket.bind(('', serverPort))'(소켓 바인딩)
- 코드: 'serverSocket.listen(1)'(연결 대기)
- 코드: 'connectionSocket, addr = serverSocket.accept()' (연결 수락)
SYN_RCVD
- 서버가 클라이언트로부터 SYN 메시지를 받고, 초기 순서 번호(y)를 선택한 후 SYN-ACK 메시지를 클라이언트로 보낸 상태이다.
- 상태 전환: LISTEN->SYN_RCVD
- 메시지: 'SYNbit=1, Seq=y' (SYN-ACK 메시지)

ESTAB(Established)
- 서버가 클라이언트로부터 ACK 메시지를 받아 연결이 설정된 상태이다.
- 상태 전환: SYN_RCVD -> ESTAB
- 메시지: ACKbit=1, ACKnum=x+1(ACK 메시지)

3-Way Handshake 과정

SYN(Synchronize)
- 클라이언트가 서버로 SYN 메시지로 보내 연결을 요청한다.
- 클라이언트: 'SYNbit=1, Seq=x'
- 클라이언트 상태: LISTEN->SYN_SENT
- 서버 상태: LISTEN->SYN_RCVD

SYN-ACK(Synchronize-Acknowledge)
- 서버가 클라이언트의 SYN 메시지를 받고, 초기 순서 번호(y)를 선택하여 SYN-ACK 메시지를 클라이언트로 보낸다.
- 서버: 'SYNbit=1, Seq=y, ACKbit=1, ACKnum=x+1'
- 클라이언트 상태: SYN_SENT
- 서버 상태: SYN_RCVD

ACK(Acknowledge)
- 클라이언트가 서버의 SYN-ACK 메시지를 받고, 이에 대한 ACK를 서버로 보낸다.
- 클라이언트: 'ACKbit=1, ACKnum=y+1
- 클라이언트 상태: SYN_SENT->ESTAB
- 서버 상태: SYN_RCVD -> ESTAB

Closing a TCP Connection

TCP 연결 종료 절차

양쪽에서 연결 종료 요청
- 클라이언트와 서버는 각각 연결을 종료하기 위해 FIN 비트가 1로 설정된 TCP 세그먼트를 보낸다.

FIN 수신 시 응답
- FIN 세그먼트를 받은 쪽은 이를 ACK(승인)하여 응답해야 한다.
- FIN을 수신하면, ACK 응답을 보낼 수 있으며, 이 ACK 응답은 자신의 FIN 요청과 함께 결합될 수 있다.

3. 동시 FIN 교환 처리 - 클라이언트와 서버가 동시에 FIN 세그먼트를 교환하는 상황도 처리할 수 있다.

Principles of congestion control

Congestion(혼잡)

비공식적으로, 너무 많은 소스가 너무 많은 데이터를 너무 빠르게 보내서 네트워크가 처리하기에 부담스러워하는 것

발생 양상

긴 진연 시간: 라우터 버퍼에 데이터가 줄을 서기에 발생
패킷 손실: 라우터의 버퍼가 오버플로우 되어 패킷이 손실됨

혼잡 제어 vs 흐름 제어

흐름 제어는 하나의 송신자가 하나의 수신자에게 너무 빠르게 데이터를 보내는 상황을 다룸
혼잡 제어는 많은 송신자가 너무 빠르게 데이터를 보내는 상황을 다룸

중요성

혼잡 문제는 네트워크 성능을 저하시킬 수 있는 주요 문제 중 하나로 간주됨(top-10-problem)

Causes/costs of congestion: scenario1

시나리오 개요

이 시나리오는 네트워크 혼잡의 가장 단순한 형태를 설명한다.
- 한 라우터와 무한 버퍼
- 입력 및 출력 링크 용량:R
- 두 개의 흐름이 존재
- 재전송 필요 없음

네트워크 구성

Host A와 Host B는 데이터를 보내고 받은 호스트이다.
라우터는 두 호스트 간의 데이터를 중계한다.
무한 버퍼는 출력 링크에서 사용된다.
입력 데이터 속도(λ_in): 호스트가 보내는 원래 데이터 속도
출력 데이터 속도(λ_out: 네트워크를 통해 전달되는 실제 데이터 속도

Q: 도착 속도(λ_in)가 R/2에 접근하면?

Causes/costs of congestion: scenario2

시나리오 개요

이 시나리오는 네트워크 혼잡의 또 다른 형태를 설명한다
- 한 라우터와 유한 버퍼
- 송신자가 분실된 데이터나 타임아웃된 패킷을 재전송함
- application layer input = application layer output(λ_in = λ_out)
- 전송 계층 입력은 재전송을 포함 (λ'_in >= λ_in)

주요 개념

라우터의 유한 버퍼
- 버퍼는 제한되어 있기에 패킷이 손실될 수 있다.
- 버퍼가 가득 차면 새 패킷은 드롭된다.

재전송
- 패킷은 손실되거나 타임아웃되면 송신자는 이를 재전송한다.
- 따라서 전송 계층 데이터 속도(λ'_in)는 원래 데이터 속도(λ_in)보다 커질 수 있다.

어플리케이션 레이어와 전송 계층
- 어플리케이션 레이어 입력과 출력은 동일하다(λ_in = λ_out)
- 전송 계층 입력은 재전송된 데이터를 포함한다.(λ'_in >= λ_in)

이상적인 상황

네트워크 혼잡을 완화하기 위해 송신자가 라우터의 버퍼 상태를 완벽하게 알고 있을 때의 이상적인 상황
packet이 라우터에서 버퍼가 가득 차서 손실될 수 있다.
- 송신자는 패킷이 손실되었음을 알게 되면, 손실된 패킷만 재전송한다.

Realistic scenario: un-needed duplicates

주요 개념
- 패킷 손실 및 재전송
  - 패킷이 라우터에서 버퍼가 가득 차서 손실될 수 있다.
  - 이로 인해 송신자는 손실된 패킷을 재전송해야한다.
- 중복된 전송
  - 송신자가 타임아웃으로 인해 패킷을 중복해서 보낼 수 있다.
  - 이 경우, 동일한 패킷이 두 번 전송되고, 둘 다 수신되면 네트워크 자원이 낭비된다.
- 네트워크 자원의 낭비
  - 불필요한 중복 전송으로 인해 네트워크 용량이 낭비된다.
  - 이는 필요한 패킷과 불필요한 중복 패킷 모두가 전달되어야 하기 때문이다.

네트워크 혼잡으로 인해 발생하는 cost
- 더 많은 작업(재전송)
  - 설명: 네트워크 혼잡이 발생하면 송신자는 손실된 패킷을 재전송해야 한다. 이로 인해 동일한 수신 속도를 유지하기 위해 더 많은 작업(즉, 재전송)이 필요하다.
  - 결과: 네트워크 리소스의 효율성이 저하되고, 송신자는 더 많은 패킷을 보내야하기에 추가적인 작업 부담이 발생한다.
- 불필요한 재전송
  - 설명: 혼잡으로 인해 링크가 동일한 패킷의 여러 복사본을 전달하게 된다. 이는 원래 데이터 패킷과 재전송된 패킷이 모두 네트워크를 통해 전달됨을 의미한다.
  - 결과: 이러한 불필요한 재전송은 네트워크의 최대 도달 가능한 처리량을 감소시킨다. 네트워크가 중복된 패킷을 전송하는데 사용되기 때문에, 실제로 유용한 데이터가 전달될 수 있는 용량이 줄어든다.

Causes/costs of congestion: scenario 3

Q. 만일 λ_in(original data), λ'_in(original data, plus retransmitted data)가 증가한다면?

A: 빨간색 데이터 스트림이 증가하면, 상단 라우터의 버퍼가 가득 차게 된다. 이로 인해 Host B에서 전송된 파란색 데이터 패킷이 라우터에 도달했을 때 모두 버려지게 된다. -> throughtput = 0

congestion의 또다른 비용

패킷 손실 시 비용: 패킷이 손실되면, 그 패킷을 위해 사용된 모든 상류 전송 용량과 버퍼링이 낭비된다.

Causes/Costs of congestion: insights

처리량(throughput)은 용량(capacity)을 초과할 수 없다.
- 네트워크의 처리량은 그 용량을 초과할 수 없다. 즉, 네트워크가 처리할 수 있는 최대 용량 이상으로 데이터를 보낼 수 없다.

용량에 근접할수록 지연이 증가한다.
- 네트워크 용량에 가까워질수록 지연 시간이 증가한다. 이는 라우터와 네트워크 장비에서 패킷이 대기열에 머무르는 시간이 길어지기 때문이다.
- 그래프에서 볼 수 있듯이, 입력률이 R/2에 도달하면 지연이 급격히 증가한다.

손실/재전송은 실질 처리량을 감소시킨다.
- 패킷 손실과 재전송은 네트워크의 실질적인 처리량을 감소시킨다. 데이터가 손실될 때마다 재전송이 필요하고, 이는 네트워크의 효율성을 저하시킨다.
- 그래프에서 손실이 발생하여 재전송되는 경우 실질 처리량이 감소하는 것을 볼 수 있다.

불필요한 중복은 실질 처리량을 더 감소시킨다.
- 필요하지 않은 중복 패킷은 네트워크의 실질적인 처리량을 더욱 감소시킨다. 이는 동일한 패킷이 두 번 이상 전송되면서 발생하는 현상이다.
- 네트워크가 이러한 중복된 패킷을 처리하는 동안 다른 중요한 데이터 전송이 지연될 수 있다.
- 그래프에서 중복 패킷이 전송되면서 처리량이 감소하는 것을 볼 수 있다.

downstream에서 손실된 패킷을 위한 upstream 전송 용량/버퍼링 낭비
- 패킷이 하류에서 손실되면, 그 패킷을 상류에서 전송하기 위해 사용된 모든 용량과 버퍼링이 낭비된다.
- 이는 네트워크 자원이 비효율적인 사용으로 이어진다.
- 그래프에서 입력률이 증가함에 따라 처리량이 증가하다가, 일정 시점 이후 급격히 감소하는 것을 볼 수 있다. 이는 상류에서 낭비된 자원 때문이다.

Approaches towards congestion control

End-end congeston control

명시적 네트워크 피트백 없음
- 네트워크에서 혼잡 상황에 대한 직접적인 피드백을 제공하지 않는다.
- 네트워크 라우터나 중간 장치가 혼잡 상황을 직접 알리지 않는다.
관찰된 손실 및 지연을 통한 혼잡 추론
- 네트워크 혼잡은 데이터 손실이나 지연 시간을 통해 추론된다.
- 패킷 손실이 발생하거나 지연 시간이 증가하면, 송신자는 네트워크가 혼잡하다고 판단한다.
TCP의 접근 방식
- TCP(Transmission Control Protocol)는 이러한 방식으로 혼잡 제어를 수행한다.
- TCP는 데이터 전송 중 발생하는 손실이나 지연 시간을 관찰하여 혼잡 상황을 추론하고, 이에 따라 데이터 전송 속도를 조절한다

Network-assistsed congestion control:

라우터의 직접 피드백
- 라우터는 혼잡한 경로를 통해 흐르는 송신/수신 호스트에 직접 피드백을 제공한다.
- 혼잡 상태를 실시간으로 감지하고, 이에 대한 정보를 송신자와 수신자에게 전달하다.

혼잡 수준 또는 전송 속도 설정
- 피드백은 네트워크의 혼잡 수준을 나타내거나. 명시적으로 송신 속도를 설정할 수 있다.
- e.g. 혼잡 정도를 표시하여 송신자가 전송 속도를 줄이도록 유도하거나, 특정 전송 속도를 제안할 수 있다.

혼잡 제어 프로토콜
- 다양한 혼잡 제어 프로토콜이 네트워크 지원 혼잡 제어를 수행한다.
- TCP ECN(Explicit Congeston Notification): TCP에서 혼잡 상황을 명시적으로 알리는 방식
- ATM(Asynchronous Transfer Mode): 비동기 전송 모드에서 혼잡 제어를 수행하는 방식
- DECbit: 라우터가 패킷 헤더의 비트를 설정하여 혼잡 정보를 전달하는 방식

TCP congestion control

TCP congestion control: AIMD

AIMD(Additive Increase, Multiplicatvie Decrease) 접근 방식

송신자는 패킷 손실(혼잡)이 발생할 때까지 전송 속도를 증가시킬 수 있으며, 손실 이벤트가 발생하면 전송 속도를 감소시킨다.

Additive Increase(AI)
- 증가: 각 RTT(왕복 시간)마다 전송 속도를 1MSS(최대 세그먼트 크기)만큼 증가시킨다.
- 목표: 손실이 발생할 때까지 전송 속도를 점진적으로 증가시켜 가능한 최대 대역폭을 찾는 것이다.
Multiplicative Decrease(MD)
- 감소: 손실 이벤트가 발생하면 전송 속도를 절반으로 줄인다.
- 목표: 네트워크 혼잡을 신속히 완화하고, 손실 이벤트 후에도 신속히 회복할 수 있도록 한다.

TCP AIMD: more

Multiplicative Decrease(다중 감소) 세부 사항

손실이 감지되었을 때 전송 속도 절반 감소
- 세 배의 중복 ACK(TCP Reno): 손실이 세 배의 중복 ACK으로 감지될 때 전송 속도를 절반으로 감소시킨다.
- 타임아웃으로 손실 감지 시(TCP Tahoe): 타임아웃으로 손실이 감지될 때 전송 속도를 1MSS(최대 세그먼트 크기)로 감소시킨다.

왜 AIMD인가

AIMD는 분산되고 비동기적인 알고리즘으로, 다음과 같은 이유로 사용된다.
- 네트워크 전체에서 혼잡한 흐름 속도 최적화
  - 네트워크의 혼잡 상태를 효과적으로 관리하고 최적의 데이터 흐름을 유지한다.
- 바람직한 안정성 특성
  - 안정적이고 예측 가능한 성능을 제공하며, 네트워크의 안정성을 보장한다.

TCP congestion control: details

TCP 전송 동작

cwnd 크기만큼 바이트를 전송하고, ACK를 받기 위해 RTT만큼 대기한 후, 추가 바이트를 전송한다.
전송 속도: TCP rate ≈ cwnd/ RTT(bytes/sec)

TCP 전송 제약

TCP 전송자는 전송을 제한한다.
- LastByteSent - LastByteAcked <= cwnd
cwnd는 네트워크 혼잡 상태를 관찰하여 동적으로 조정된다.(TCP 혼잡 제어를 구현함)

TCP slow start

TCP 느린 시작은 연결이 시작될 때 전송 속도를 기하급수적으로 증가시키는 알고리즘이다. 이는 초기 전송 속도를 천천히 증가시켜 혼잡을 방지하는 데 도움을 준다.

동작 원리

초기 값: 처음에는 혼잡 윈도우(cwnd)가 1MSS(Maximum Segment Size)로 설정된다.
속도 증가:
- 매 RTT(Round-Trip-Time)마다 cwnd가 두 배로 증가시킨다.
- 각 ACK를 받을 때마다 cwnd를 증가시켜 전송 속도를 높인다

요약

초기 전송 속도는 느리지만, ACK를 받을 때마다 cwnd를 증가시키므로 전송 속도가 기하급수적으로 빠르게 증가한다.

TCP: from slow start to congestion avoidance

Q. 지수 증가(exponnential increase)에서 선형 증가(linear increase)로 언제 바뀌는가?
A: 'cwnd(혼잡 윈도우 크기)'가 타임아웃 전에 최대값의 절반에 도달했을 때

구현 세부사항

변수 ssthresh
- ssthresh는 혼잡 회피를 위해 설정되는 임계값
- 패킷 손실 이벤트 발생 시, ssthread는 손실 이벤트 직전의 cwnd 값의 절반으로 설정된다.

Summary : TCP congestion control

TCP CUBIC

TCP CUBIC은 AIMD(가산적 증가, 곱셈적 감소) 방식보다 더 나은 대역폭을 탐색하는 방법을 제시한다.

W_max

W_max는 혼잡 손실이 감지된 전송 속도를 의미한다.
병목 링크의 혼잡 상태는 아마도 많이 변하지 않았을 가능성이 크다.

새로운 접근 방식

손실 발생 후 전송률/윈도우를 반으로 줄인 후, 처음에는 W_max 까지 빠르게 램프업하지만, 이후에는 더 천천히 W_max 에 접근한다.

TCP CUBIC은 AIMD보다 효율적으로 대역폭을 사용할 수 있는 알고리즘이다.

K
- K는 TCP 윈도우 크기가 W_max에 도달하는 시점을 나타낸다.
- K 자체는 튜닝이 가능하다.
증가 방식
- W(윈도우 크기)는 현재 시간과 K 사이의 거리를 큐브 함수로 증가시킨다.
- K에서 멀리 떨어져 있을 때는 더 큰 증가
- K에 가까울 때는 더 작은 증가(신중한 증가)
TCP CUBIC의 장점
- TCP CUBIC은 리눅스의 기본 설정이며, 인기 있는 웹 서버에서 가장 많이 사용되는 TCP이다.

TCP and the congested "bottlenet link"

TCP(classic, CUBIC): 두 가지 버전의 TCP 모두 패킷 손실이 발생할 때까지 전송 속도를 증가시킨다. 이 패킷 손실은 라우터의 출력에서 발생하며, 이를 "bottleneck link" 라고 한다.

혼잡 이해(understanding congestion): 혼잡을 이해하려면 혼잡한 병목 링크에 집중하는 것이 유용하다.

insight: TCP 전송 속도를 증가시키면, 측정된 RTT(왕복 시간)가 증가하지만, 혼잡한 병목 링크에서는 종단 간 처리량이 증가하지 않는다.

goal: 종단 간 파이프를 "가득 채우되 더 가득 차지 않게" 유지하는 것이다. 이는 TCP 전송 속도가 병목 링크의 처리 용량을 초과하지 않도록 조절해야 한다는 의미이다.

Delay-based TCP congestion control

Delay-based TCP 혼잡 제어는 송신자와 수신자 간의 파이프를 "충분히 채우지만 더 많이 채우지 않기" 위해 병목 링크를 바쁘게 유지하면서 높은 지연과 버퍼링을 피하려고 한다. 이는 네트워크 경로의 혼잡 상태를 RTT(왕복 시간)를 통해 감지하고 제어하는 방식이다.

RTTmeasured(측정된 RTT)
- 현재 네트워크 경로의 왕복 시간을 측정한다.
RTTmin(최소 RTT)
- 혼잡하지 않은 경로에서 관찰된 최소 RTT이다. 이를 기준으로 혼잡하지 않은 상태를 판단한다.
measured throughtput(측정된 처리량)
- 최근 RTT 간격 동안 전송된 바이트 수를 측정된 RTT로 나눈 값이다.
cwnd(혼잡 창)
- 송신자가 네트워크 경로에 한 번에 보낼 수 있는 데이터 양을 제어하는 윈도우 크기이다. 혼잡 제어의 주요 변수이다.

지연 기반 접근 방식(Delay-based Approach)

네트워크 혼잡을 유도하거나 강제적으로 패킷 손실을 일으키지 않고도 혼잡을 제어하는 방법이다.
RTTmin: 혼잡하지 않은 경로에서의 최소 RTT이다. 이는 네트워크의 최소 지연을 나타내며, 혼잡하지 않은 상태를 기준으로 삼는다.
혼잡하지 않은 처리랑(uncongested throughtput):
- 혼잡 창을 기준으로 한 혼잡하지 않은 상태의 처리량은 'cwnd / RTTmin' 으로 계산된다.

알고리즘

측정된 처리량이 혼잡하지 않은 처리량에 "매우 가까운" 경우
- 경로가 혼잡하지 않다고 판단하고 cwnd를 선형적으로 증가 시킨다.
측정된 처리량이 혼잡하지 않은 처리량에 "훨씬 미치지 못하는" 경우
- 경로가 혼잡하다고 판단하고 cwnd를 선형적으로 감소시킨다.

주요 포인트

혼잡 제어 without inducing/forcing loss
- 패킷 손실을 유도하거나 강제하지 않고도 혼잡을 제어할 수 있다.
Maximizing throughtput while keeping delay low
- 네트워크 경로의 파이프를 충분히 채우지만 더 많이 채우지 않기 위해 최대 처리량을 유지한다.
- 이는 지연을 낮게 유지하는 동시에 처리량을 최대로 유지하려는 것이다.
다수의 지연 기반 접근 방식을 사용하는 TCP
- 여러 배포된 TCP가 지연 기반 접근 방식을 채택하고 있다.
- 예를 들어, Google's 내부 백본 네트워크에서 배포된 BBR(Bottleneck Bandwidth and RTT) 혼잡 제어 알고리즘이 있다.

Explicit congeston notification(ECN)

Explicit Congestion Notification(ECN)은 TCP 네트워크에서 혼잡을 통지하는 네트워크 보조 혼잡 제어 메커니즘이다. 이를 통해 네트워크는 혼잡을 감지하고 이를 발신자에게 알릴 수 있다.