Move Fast

▶ Congestion Control

- 너무 많은 출발지(네트워크 장비)에서 네트워크가 감당하기에는 너무 많은 데이터를 너무 빠르게 전송하여 발생하는 네트워크 혼잡 현상이다.

- 징후

• 라우터에서 버퍼가 오버플로우되어 패킷 손실의 발생
• 라우터 버퍼에서 긴 큐잉 지연(Queueing delay) 발생

- 흐름 제어(Flow Control)와는 다르다.

▶ 라우터가 무한한 크기의 버퍼를 갖는 경우

- 출력 링크의 수용력을 R이라고 가정했을 때,

• 전송률이 아무리 커도 링크 처리량(수용력)은 R/2을 넘을 수가 없다.
• 지연 시간이 지수적으로 증가하므로 혼잡 시 큰 지연이 발생한다.

▶ 라우터가 유한한 크기의 버퍼를 갖는 경우

- 송신측에서는 타임아웃된 패킷(손실 패킷)의 재전송이 이루어진다. 즉, 큐가 유한할 경우 패킷의 손실이 발생한다.

• (λin : 입력 버퍼에 패킷이 들어오는 속도, λout : 출력 버퍼의 송신 속도)
• 입력 버퍼의 속도와 출력 버퍼의 속도가 같은 경우 : λin = λout
• 전송 계층의 입력 버퍼의 속도가 재전송 속도까지 포함할 경우 : λ'in = λout

[왼쪽부터 가장 이상적인 상황, 덜 이상적인 상황, 가장 현실적인 상황]

- 가장 이상적인 상황 : 라우터 버퍼가 이용가능할 때만 송신측에서 패킷을 전송하므로 어떤 패킷의 손실도 발생하지 않음.

λin = λ'in = λout

- 덜 이상적인 상황 : 라우터 버퍼가 꽉 차서 패킷이 손실될 수 있으므로 송신자는 패킷이 손실되었을 때만 재전송한다.

λ'in > λout

- 가장 현실적인 상황 : 라우터 버퍼가 꽉 차서 패킷이 손실될 수 있고, 패킷이 크게 지연되어 송신측의 타이머가 타임아웃될 수 있으므로, 두 상황 모두 재전송한다. 즉, 패킷의 큰 지연으로 불필요한 재전송이 늘어난다.

λ'in >> λout

- 혼잡 비용

• 손실된 패킷을 재전송한다.
• 큰 지연으로 인한 불필요한 재전송이 발생 => 라우터가 패킷의 불필요한 복사본을 포워드(입력버퍼->출력버퍼)하는데 링크의 대역폭을 사용하므로 네트워크 자원이 비효율적으로 사용된다.

▶ 여러 개의 네트워크 장비를 거쳐가는 경우

- λ'in : 재전송을 포함하여 입력버퍼에 패킷이 들어오는 속도

- 데이터의 traffic이 증가하게 되므로 혼잡이 커지고 지연 시간이 길어진다.

- λ'in 이 계속 증가하게 되면(재전송 발생 증가), 패킷이 경로 상에 버려지는 상황이 증가한다는 뜻으로, 버려지는 지점까지 패킷을 전송하기 위해 상위 라우터에서 사용되는 전송 용량은 낭비된다.

▶ AIMD (Additvie Increase Multiplicative Decrease)

- 혼잡 윈도우 크기(Congestion Window Size, cwnd) : 수신측의 윈도우 크기(rwnd)에 영향을 받으며, 송신측에 있는 윈도우 크기이다.

- 전송 후 ACK받지 못한 세그먼트들 : LastByteSent - LastByteRead <= cwnd <= rwnd

- 송신측에서 ACK를 못받고 타임아웃되면 패킷 손실이 발생한 것으로 알고 Congestion으로 받아들인다. 따라서 송신측은 윈도우 크기(cwnd)를 줄여서 데이터 전송 속도를 조절한다.

- 송신측에서 패킷의 손실이 발생할 때까지 이용가능한 대역폭을 탐지하면서 전송률(Congestion Window Size, cwnd)을 증가시킨다.

- 가법적 증가(Additive Increase) : 손실이 발견될 때까지 매 RTT(왕복시간)마다 1MSS씩 cwnd를 증가시킨다. 추가로 매 ACK마다 cwnd는 MSS * (MSS/cwnd) 바이트씩 증가한다.

- 승법적 감소(Multiplicative Decrease) : 손실이 발생한 후에 cwnd를 절반으로 감소시킨다.

- 그래프 상에서 cwnd 값이 톱니 모양의 패턴을 가지게 된다. 값이 꺾일 때마다 패킷의 손실이 발생한 것이다.

▶ Congestion Control Details

- 송신자에서 ACK받지 않은 데이터 양을 제한하여 송신률을 제한한다.

- 송신자의 송신률(Bytes/sec):

- 송신자의 혼합감지

• 손실 이벤트 : 타임아웃 또는 3개의 중복 ACK
• 손실 이벤트가 발생하면 송신률을 감소시킨다.

- 혼잡제어 알고리즘의 3가지 요소

• AIMD
• 슬로 스타트(slow start)
• 타임아웃에 대한 반응

▶ Slow Start

- TCP 연결이 시작될 때 혼잡 윈도우 크기(cwnd)의 초기값은 1MSS 이다.

- TCP 연결이 시작한 이후 데이터의 첫 번째 손실이 발생하기 전까지 송신률을 지수적으로 증가시킨다.

- 매 RTT마다(오류없이 ACK가 올때마다) cwnd는 2배씩 증가한다.

- 즉, 연결가능한 대역폭이 MSS/RTT(송신률)보다 아주 큰 경우, 송신률은 cwnd와 비례하므로 초기에는 느리지만 지수적으로 빠르게 증가한다.

▶ 타임아웃에 대한 반응

- TCP Tahoe : 타임아웃 또는 3개의 중복ACK 상황에서 항상 cwnd를 1 MSS 로 설정한다.

- 타임아웃에 의해 감지된 손실 : 전혀 전송되지 않은 것으로 간주하고, 심각한 혼잡 상황으로 받아들인다.

• cwnd = 1MSS (Slow Start 발생)
• cwnd는 지수적으로 증가하다가 임계값(threshold)에 달하면, 선형적으로 증가(혼잡 회피)한다.

- 3개의 중복 ACK에 의해 감지된 손실 : 다른 세그먼트(or 패킷)는 잘 도착했으므로 일부 세그먼트들은 전송해도 된다는 것으로 간주하고, 조금 혼잡한 상황으로 받아들인다.

• TCP Reno : cwnd는 절반으로 감소하고 이후에 선형적으로 증가한다.
• 이전의 TCP Tahoe 는 슬로 스타트(Slow Start)로 진입한다.

[ Loss 발생 시, TCP Tagoe는 1MSS로 뚝 떨어짐, TCP Reno 절반으로 떨어짐 ]

- cwnd 값이 타임아웃 전의 1/2 크기에 도달할 때, 지수적 증가는 선형적 증가로 변경된다.

- 가변적 임계값(variable threshold) 설정 : 손실 이벤트가 발생 시 임계값을 손실 이벤트 전의 cwnd의 1/2 크기로 설정한다.

[전체적인 구상도] 

▶ Throughput

- cwnd와 RTT 함수로써 TCP의 평균처리율은 슬로스타트는 무시하고, 항상 전송한 데이터로 추정한다.

- 평균 처리율 

- 손실이 발생하면 윈도 크기는 1/2로 감소하고 전송률도 비례하므로 1/2로 감소한다.

- cwnd가 커지면 처리율이 증가(데이터 전송 속도가 빨라짐)하므로 Congestion도 증가한다.

- 미래에 장거리 및 고속링크일 경우 cwnd = 83,333 만큼 요구되는데 이는 많은 양의 세그먼트이며 손실 가능성이 높다.

- 손실 관점에서 평균 처리율 (L:손실률)

- 고속 환경을 위한 새로운 버전의 TCP 연구가 필요하다.

▶ 공평성 (TCP Fairness)

- K 개의 TCP 연결이 R bps의 전송률(대역폭)의 병목 링크(bottleneck link)를 통과하는 경우, 각 연결의 평균 전송률이 R/K에 가깝다면 TCP 혼잡제어 메커니즘은 공평하다.

- 공평한 이유는 이상적으로 두 처리율의 합은 R과 같아야 한다.

(동등한 대역폭 공유와 전체 대역폭 이용선의 교차 지점 가까운 곳의 처리율)

- 공평성과 UDP

• 멀티미디어 애플리케이션들은 TCP를 사용하지 않으므로, 혼잡제어로 인한 전송 the고 조정을 하지 않는다.
• UDP의 사용은 일정한 속도로 음성과 영상을 전송하며 패킷 손실을 감수한다.
• TCP관점에서 UDP는 공평하지 못한데, 그 이유는 다른 연결과 협력하지 않고, 전송률 조절도 하지 않기 때문이다. 이 부분에 대하여 UDP가 TCP Traffic을 밀어낼 가능성이 있다.
• 관련 연구 분야로는 UDP 트래픽으로 dsl한 인터넷 마비 방지하는 혼잡제어 방식이 있다.

- 명확한 혼잡 제어 통보 (Explicit Congestion Notification, ECN)

• IP헤더의 Tos 필드에 2비트가 Congestion을 나타내기 위해 네트워크 라우터에 의해 값이 저장된다.
• 즉, 네트워크 장비(라우터)가 Congestion을 감지하고 호스트에게 알려준다.
• 주로 심각한 상황이 되면, 송신측의 혼잡을 알리기 위해 수신측에서 ACK세그먼트의 ECE 비트를 설정한다.

▶ 연결 설정

- 송신자와 수신자는 세그먼트를 교환하기 전에 연결 설정(Handshaking)을 한다.

- TCP 변수 초기화 : 순서번호, 버퍼 및 흐름제어 정보(수신윈도우)

- 클라이언트 : 연결 요청

Socket clientSocket = new Socket("hostname", "port number");

- 서버 : 클라이언트 연결 승인

Socket connectionSocket = welcomeSocket.accept();

▶ 3-Way Handshake

- 1단계 : 클라이언트는 SYN 비트 플래그(flag)를 설정하고 서버에 SYN 세그먼트를 전송한다. 최초의 순서번호를 기술한다.

* SYN 세그먼트 : 연결 요청 때에만 세그먼트의 헤더에 flag필드에 1비트의 값을 가진 세그먼트로, 데이터는 없다.

- 2단계 : 서버는 SYN 세그먼트를 받고, 클라이언트에게 SYNACK 세그먼트를 전송한다. 서버는 TCP 버퍼와 변수를 할당한 뒤, 서버의 최초 순서번호를 기술한다.

- 3단계 : 클라이언트는 SYNACK를 받고, ACK 응답을 서버에게 보낸다. 클라이언트는 TCP 버퍼와 변수를 할당한다. ACK응답에는 데이터가 포함될 수 있다.

▶ 연결 해제

- 클라이언트와 서버 각각 서로에게 FIN 세그먼트를 전송한다.

- FIN과 ACK는 하나의 세그먼트에 같이 포함될 수도 있다.

- 클라이언트가 연결을 종료하는 경우를 가정해본다.

ClientSocket.close();

- 1단계 : 클라이언트는 세그먼트 헤더에 FIN비트 플래그(flag)를 설정하고, 서버에 FIN 세그먼트를 전송한다.

- 2단계 : 서버는 FIN 세그먼트를 받고, ACK 세그먼트를 전송한다. 연결을 종료하고, FIN 세그먼트를 클라이언트에게 전송한다.

- 3단계 : 클라이언트는 서버로부터 FIN 세그먼트를 받고, ACK 세그먼트를 서버로 전송한다. 이후 대기 시간(timed wait)동안 기다린 후, 연결 종료된다.

- 4단계 : 서버는 클라이언트로부터 ACK 응답을 받고, 연결 종료된다.

▶ Fast Retransmit (빠른 재전송)

- 재전송 타이머 값이 종종 상대적으로 길어지므로, 손실된 패킷의 재전송 전에 지연시간이 커진다.

- 위의 상항을 해결하고자 중복 ACKs를 통해 손실된 세그먼트를 검출한다.

- 송신측에서 바로바로 여러 개의 세그먼트를 전송할 경우, 세그먼트가 손실되면 수신측에서는 중복 ACK를 보내게 되는데, 타임아웃 전에 송신측에서 중복 ACK를 3번받게 되면 세그먼트를 즉시 전송한다. 즉, 수신측이 기다리는 순서번호의 세그먼트보다 큰 순서번호의 세그먼트가 3개 도착할 경우를 의미한다.

[ ACK2 의 중복수신 3번 이후 3번 데이터 즉시 전송 ]

▶ Flow Control

- TCP 송신자가 데이터를 너무 빠르게 또는 너무 많이 전송하여 수신버퍼가 오버플로우(Overflow)하는 것을 방지한다.

- TCP의 수신자는 수신버퍼(receive buffer)를 가지는데, 상위 계층으로 세그먼트를 보내는 애플리케이션 프로세스가 수신버퍼로부터 데이터를 읽는 속도가 느릴 수 있다.

- 목표 : 애플리케이션 프로세스의 읽는 속도 = 송신자가 데이터를 전송하는 속도

- 즉, 흐름제어는 속도를 일치시키는 서비스이다.

- Receive Window(rwnd) : 수신버퍼의 가용 바이트 수로, 송신 윈도우 크기를 결정한다.

LastByteRcvd - LastByteRead <= RcvBuffer

[밑에서 수신 받은 번호 - 위로 올려 보낸 번호 = 수신했지만 상위계층으로 전송되지 않은 데이터들]

=> 항상 수신 버퍼보다 작아야한다. 초과하면 오버플로우 발생.

rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)

    = RcvBuffer - (수신했지만 상위 계층으로 전송하지 않은 데이터들)

- 수신자는 TCP헤더에 수신버퍼안에 있는 여유공간(Receive Window, rwnd) 값을 포함함으로써 버퍼에 공간이 있음을 송신자에게 알린다.

- 수신버퍼의 크기는 소켓의 옵션을 통해 설정되는데 디폴트 값이 4096바이트이다.

▶ TCP Overview

- 점대점(Point-to-Point) : 단일 송/수신자간의 통신   ex) 일대일 통신, Unicast 전송

• Unicast : 고유 주소로 식별된 하나의 네트워크 목적지에 메시지를 전송하는 방식
• Broadcast : 송신 가능한 모든 목적지에 동일한 데이터를 전송
• Multicast : 특별한 주소 지정 방식을 통해 정해진 여러 목적지로 데이터를 전송
• 호스트가 무수히 많은 경우, Unicast로 데이터를 전송하면, 각각의 네트워크 연결마다 호스트의 컴퓨팅 리소스(자원)을 소비할 뿐 아니라 각각 다른 네트워크 대역폭을 필요로 하기 때문에 전송 비용이 많이 든다는 단점이 있다.

- 파이프라인(Pipeline) : TCP의 혼잡 제어 및 흐름 제어가 윈도우 크기(Window size)를 결정한다.

• Window size : ACK받지 않은 데이터 중 최대 송신가능한 바이트 수, 수신자가 한 번에 버퍼링할 수 있는 최대 데이터 크기
• Sliding Window : 두 개의 네트워크 호스트 간의 패킷의 흐름을 제어하기 위한 방법으로, TCP 프로토콜은 데이터의 전달을 보증해야 하므로 패킷 하나 하나가 정상적으로 전달되었음을 알리는 확인 신호(Acknowledgement, ACK)를 수신자가 송신자에게 보내야 한다.
• 패킷에 오류가 생겼을 경우, 송신측에서 해당 패킷을 재전송해야 하는데 이 때 Sliding Window가 Window Size(메모리 버퍼의 일정 영역)에 포함되는 모든 패킷을 전송하고, 패킷의 전달이 확인되는 대로 이 Window를 옆으로 옮김(Sliding)으로써 그 다음 패킷들을 전송할 준비를 한다.

- 전이중성 데이터(Full-duplex Data) : 같은 연결 상에서 양방향 데이터 흐름

- 최대 세그먼트 크기 (Maximum Segment Size, MSS)

• 헤더를 제외하고 TCP가 실을 수 있는 최대 데이터 크기
• 기본값은 IPv4 -> 536 Byte, IPv6 -> 1220 Byte이다. 
• 최대 전송 단위(MTU)에 의해 값이 결정되며, MSS값은 헤더의 MSS 옵션 필드에 저장된다.
• 연결에 참여하는 두 장비가 서로 다른 MSS값을 갖을 수도 있다.

- 최대 전송 단위(Maximum Transmission Unit, MTU)

• 데이터 링크(2계층) 또는 네트워크(3계층)에서 하나의 프레임 또는 패킷에 담아 운반할 수 있는 헤더를 포함한 최대 데이터 크기
• 최소 권고값은 2계층 기준 1500Byte이며, 3계층 기준 IPv4는 MSS 크기에서 40byte(IP헤더+TCP헤더)를 추가한 576Byte이고, IPv6는 1280Byte이다.
• 실제로는 최대 65,646바이트 범위까지 생성가능하다.

- MTU가 IP 기반의 정보인 반면, MSS는 TCP 기반의 정보이다.

- TCP는 연결지향형으로 제어 메시지들의 교환(Handshaking)이 이루어진다. 핸드쉐이킹을 통해 데이터 교환 전에 송신자 및 수신자의 상태를 초기화한다.

- 흐름 제어(Flow Control) : 수신자의 속도에 맞춰서 송신자가 데이터를 보낸다.

▶ TCP Segment

- Source port number : 출발지 포트 번호

- Destination port number : 도착지 포트 번호

- Sequence number : 순서번호(Seq#)로, 세그먼트에서 첫 번째 바이트의 바이트 스트림 번호값이 저장된다.

- Response number : 확인응답(누적된 ACK)번호로, 상대방으로부터 받아야할 다음 바이트의 순서번호값이 저장된다.

ex) ACK100이 들어있으면 99번 데이터까지 잘 받았음을 의미한다.

- Header length : 헤더의 길이로, Option이 없으면 헤더값에 5개의 비트값이 들어간다. 그러나 일반적으로 32비트이다.

- Reservation : 나중에 다시 설명

- Control flag 

• 구체적으로 flag순서는 URG, PSH, RST, SYN, FIN이고 각각 1비트로 표현되는 값이 저장된다.

• 중요한 부분만 집어보자면, 통신과정에서 연결 설정이 필요할 때 RST, SYN, FIN을 사용한다. 

• RST는 연결을 재설정(Reset)할 때 연결을 종료하기 위한 비트값으로 비정상적인 세션 연결 끊기가 해다된다. 

• 연결 요청 시에는 SYN=1 의 비트값을 넣어 세그먼트를 전송한다.

• 연결 해제할 때는 FIN=1 의 비트값을 저장하여 세그먼트를 전송한다.

- Window : 수신측의 윈도우 크기(Window size)로, 받을 수 있는 최대 데이터 크기값이 저장되어 있다.

- TCP Checksum : 검사합(Checksum)이 저장되는 데, 체크섬값이란 세그먼트의 합에 1의 보수를 취한 값을 말하며, 수신측에서 체크섬과 세그먼트의 실제 데이터를 더한 결과를 통해 오류를 검출한다.

- Emergency Data point : 생략

- Option : 변수의 길이로 설명은 생략.

- Data : 헤더를 제외한 실제 세그먼트에 들어있는 데이터의 크기로 MSS에 의해 제한되어진다.

▶ TCP Round Trip Time, Timeout

- TCP는 신뢰적인 데이터 전송(RDT)처럼 세그먼트의 손실을 발견하기 위해 타임아웃/재전송 메커니즘을 사용한다. 이 때, 송신측에서 데이터를 전송한 후, ACK받기까지 걸린 시간을 RTT(Rount Trip Time)이라 표현한다.

- 타임아웃(timeout) 주기는 RTT보다 길어야 한다. 너무 짧으면 타임아웃이 자주 발생하여 세그먼트의 불필요한 재전송이 발생하므로 링크를 비효율적으로 사용하게 된다. 반대로 너무 길게 되면, 세그먼트의 손실에 대한 느린 대응으로 회복이 비효율적이게 된다.

- SampleRTT : 세그먼트가 송신된 시간부터 ACK 받기까지 측정된 시간으로, 재전송한 세그먼트는 무시한다. 값은 네트워크 부하에 따라 가변적이다.

- 현재 SampleRTT 값이 아닌 최근의 값들의 평균값으로 추정한다.

- 추정RTT : EstimatedRTT = (1-a) * EstimatedRTT + a * SampleRTT

일반적으로 a=0.125이고, 지수적 가중 이동 평균(EWMA)방식으로 과거 샘플들의 영향이 지수적으로 감소한다. a가 높을수록 SampleRTT에 더 영향을 준다.

- DevRTT : RTT 변화율로, SampleRTT와 EstimatedRTT의 편차값이다. 즉, 현재 RTT값이 추정 RTT값으로부터 얼마나 벗어났는가에 대한 정보이다.

- 재전송 타임아웃 주기 (Timeout Interval) = EstimatedRTT + 4 * DevRTT

- 타임아웃나서 세그먼트를 재전송하게 되면, 재전송한 세그먼트에 대한 타이머가 시작된다.

▶ TCP의 RDT

- TCP는 비신뢰적인 인터넷 네트워크 계층(IP서비스)의 상위 계층에서 신뢰적인 데이터 전달(Reliable Data Transfer, RDT) 서비스를 제공한다.

- 파이프라인되는 세그먼트 (ACK의 응답이 없어도 다수의 세그먼트를 전송가능)

- 누적된 ACKs

- 단 하나의 재전송 타이머

- 재전송은 타임아웃이 되거나, 중복 ACKs를 수신했을 경우 발생한다.

- “간소화된 TCP 송신자”는 중복 ACKs를 무시하고 흐름제어 및 혼잡제어를 무시한다.

▶ TCP 송신자의 3가지 상황(Sender Events)

- 상위 계층으로부터 수신된 데이터 : 데이터를 받았으므로 상위 계층으로부터 데이터 전송 요청이 오게 된다.

• 순서번호(Seq#)를 가진 세그먼트 생성 (Seq# : 세그먼트의 첫 번째 바이트의 바이트 스트림 번호)

• 타이머가 실행되지 않고 있으면 타이머를 시작한다.

• 타이머의 만료주기는 Timout Interval 로 계산한다.

- 타임아웃 : 타임아웃에 의해 세그먼트가 재전송되고, 전송했으나 ACK 받지 않은 가장 오래된 세그먼트에 대해 타이머가 다시 시작한다.

- ACK를 수신한 경우 : 이전에 ACK받지 않은 세그먼트의 ACK 이면, 해당 세그먼트를 ACK 응답된 세그먼트로 표시한다. 즉, 윈도우 크기를 조정한다. 아직 ACK받지 못한 세그먼트들이 존재한다면 타이머를 시작한다.

NextSeqNum = InitialSeqNum

SendBase = InitialSeqNum   //송신했으나 ACK되지 않은 가장 오래된 순서 번호

loop(forever) {

switch(event) {

event : data received from application above // 상위 계층으로부터 수신된 데이터

create TCP segment with sequence number NextSeqNum // 다음 순서번호를 가진 TCP 세그먼트 생성

if(timer currently not running) { // 아직 타이머가 시작하지 않았다면

    start timer //타이머 시작

}

pass segment to IP // 생성한 세그먼트 목적지 IP주소로 전송

NextSeqNum = NextSeqNum + length(data) // 전송할 세그먼트의 순서번호 변경

event : timer timeout // 타임아웃

retransmit not-yet-acknowledged segment with smallest sequence number

start timer

event : ACK received, with ACK field value of y //y번의 ACK를 수신한 경우

if (y > SendBase) { // 누적된 ACK가 도착한 경우(새 데이터가 온 경우)

SendBase = y;

if (there are currently not-yet-acknowledged segments) { //아직 ACK받지 않은 데이터가 남은 경우

    start timer //타이머 시작

}

}

}

}

- 세 가지 상황에 대한 재전송 시나리오

▶ TCP 수신자의 4가지 상황(Receiver Events)

<문제가 없는 상황>

- 기다리는 순서번호의 세그먼트가 도착. 즉, 이전의 데이터들은 모두 ACK받은 경우

 => 지연된 ACK 발생. 다음 세그먼트를 위한 500ms의 ACK타이머가 설정되고, 시간 안에 다음 세그먼트가 오지 않을 경우 ACK를 전송한다.

[ 오른쪽이 지연된 ACK의 모습 ]

- 기다리는 순서번호의 세그먼트가 도착. 하나의 다른 세그먼트가 ACK 지연시간(500ms)안에 수신된 경우

 => 하나의 누적 ACK를 송신측으로 즉시 전송한다.

<문제가 있는 상황>

- 기다리는 것보다 높은 순서번호를 가진 세그먼트가 도착. 즉, 송신측에서 여러 개의 세그먼트를 전송한 후 중간 세그먼트가 손실된 경우 => 즉시 기다리는 바이트의 순서번호에 해당하는 중복 ACK를 전송한다. 이 때, 보낼 세그먼트가 없더라도 ACK를 위해 헤더만 별도로 생성하여 송신측으로 전송한다. (ACK는 항상 세그먼트의 헤더에 포함되어 있음 - piggybacked ACK 방식)

- 위의 상황에서 발생한 갭(손실된 세그먼트)를 부분적으로 또는 모두 채워주는 세그먼트가 도착한 경우 => 부분적으로 도착하면 아직 받지 못한 세그먼트 중 가장 낮은(오래된) 순서번호의 ACK를 전송한다. 모두 도착했다면 위의 상황에서 높은 순서번호를 가진 세그먼트의 다음 세그먼트의 순서번호를 가진 ACK를 전송한다.

[ 왼쪽은 중복ACK, 오른쪽은 갭을 채우는 세그먼트가 모두 도착한 경우 ]