Transport Layer 2

Study, Computer Network

Transport Layer

Posted Jul 11, 2022

Transport Layer 1

Link: ind2x.github.io/posts/Transport_Layer/

혼잡제어의 원리

네트워크 혼잡 원인을 처리하기 위해서 네트워크 혼잡을 일으키는 송신자를 억제하는 메커니즘이 필요하다.

혼잡의 원인과 비용

혼잡제어가 발생하는 단계적으로 복잡해지는 세 가지 시나리오들을 살펴본다.

각 경우에서 왜 혼잡이 발생하는지와 그 혼잡비용에 대해 먼저 살펴본다.

시나리오 1

시나리오1은 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터이다.

가장 간단한 혼잡제어 시나리오로 호스트 A,B가 호스트 C,D로 데이터를 전송하는데 경로 상에 A,B와 C,D 사이에는 각각 단일 홉이 있고 그 홉을 연결하는 무한 버퍼를 가진 라우터가 있으며 신뢰적 연결이 아닌 단순히 데이터를 캡슐화해서 전송하기만 한다고 가정한다.

이 때, 라우터는 용량 R의 출력 링크를 갖는다.

위의 그림은 호스트 A의 연결 성능을 나타낸 것이다.

왼쪽 그래프는 “연결당 처리량” (수신자측에서의 초당 바이트 수)을 그린 것으로, 0부터 R/2 까지는 송신자의 전송률과 수신자의 처리량이 같다.

하지만, 전송률이 R/2 이상일 땐, 수신률은 여전히 R/2인데 그 이유는 송신자가 2명인데 용량이 R인 링크가 하나이기 때문이다.

R/2의 연결당 처리량을 얻는 것은 목적지에 패킷을 전달하는 데 링크를 최대로 활용하므로 좋은 현상이다.

그러나 오른쪽 그래프를 보면, 전송률이 R/2에 근접할 때 평균 지연이 증가한다.

전송률이 R/2를 초과할 때, 라우터 안에 큐잉된 패킷의 평균 개수는 제한되지 않고, 출발지와 목적지 사이의 평균 지연이 무제한이 된다.

따라서 R 근처의 전체 처리량에서 동작하는 것은 처리량 관점에서는 이상적이나, 지연 관점에서는 이상적이지 않다.

즉, 이 시나리오의 네트워크 혼잡 비용은 패킷 도착률이 링크 용량에 근접함에 따라 큐잉 지연이 커진다.

시나리오 2

시나리오2는 1에서 라우터의 버퍼가 유한하고, 신뢰적인 연결이라 가정한다.

시나리오2에서의 성능은 재전송이 어떻게 수행되는지에 따른다.

먼저 비현실적인 경우로 라우터에 있는 버퍼가 비어있을 때만 패킷을 송신한다는 가정이다.

이 경우 성능을 보여주는 그래프는 위의 3.46(a)이다.

처리율 관점에서 보면, 송신된 모든 것이 수신되기 때문에 성능은 이상적이며, 패킷 손실이 절대로 발생하지 않으므로 이 시나리오에서 송신율은 R/2를 초과할 수 없다.

또한 R/2까지의 송신율과 수신자의 처리율은 동일하다.

두 번째는 패킷이 확실히 손실된 것을 알았을 때만, 송신자가 재전송하는 좀 더 현실적인 경우다.

이 경우 3.46(b)가 그 성능이다.

최초의 데이터 전송과 재전송합의 속도가 R/2라 가정하면, 이 값에서 수신자 애플리케이션으로 전달되는 데이터의 전송률은 R/3이다.

그러므로 전송된 데이터의 R/2 중 0.333R 바이트는 원래의 데이터고, 초당 0.166R 바이트는 재전송 데이터이다.

여기서 혼잡 네트워크 비용은 송신자는 버퍼 오버플로 때문에 버려진 패킷을 보상하기 위해 재전송을 수행해야 한다.

마지막으로 송신자에서 너무 일찍 타임아웃 되어 패킷이 손실되지 않았으나 큐에서 지연 중인 패킷을 재전송한 경우다.

이 경우 원래의 데이터 패킷과 재전송 패킷 둘 다 수신자에게 도착한다.

물론 수신자는 하나의 패킷만 필요하므로 재전송된 패킷은 버린다.

여기서 발생하는 혼잡 비용은 커다란 지연으로 인한 송신자의 불필요한 재전송은 라우터가 패킷의 불필요한 복사본들을 전송하는데 링크 대역폭을 사용하는 원인이 된다.

그림 3.46(c)를 보면 각 패킷이 라우터에 의해 두 번씩 전달된다고 가정했을 때, 제공된 부하에 대한 처리량을 나타낸 것으로 각 패킷이 두 번씩 전달되므로 제공된 부하가 R/2일 때 처리량은 R/4의 점선값을 가질 것이다.

시나리오 3

시나리오3은 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로이다.

4개의 호스트는 위의 그림처럼 겹쳐지는 2-홉 경로를 통해 패킷을 전송한다.

예를 들면, R2에 도착하는 B-D 트래픽이 A-C 트래픽 보다 클 수 있다.

A-C와 B-D 트래픽은 R2에서 버퍼공간을 경쟁해야 하므로, R2를 성공적으로 통과하는 A-C 트래픽 양은 B-D에서 제공된 부하가 크면 클수록 더 작아진다.

극단적인 경우, 제공된 부하가 무한대에 가까워 짐에 따라, R2의 빈 버퍼는 즉시 B-D의 패킷으로 채워지고, R2에서의 A-C 연결의 처리량은 0이 된다.

즉, 트래픽이 많은 경우 A-C 종단간 처리율이 0이 된다는 것으로, 아래 그래프에서 보이는 것처럼, 제공된 부하와 처리량 간의 tradeoff가 발생함을 보여준다.

서로 같은 경로를 지나는 순간이 존재하면 서로의 영향을 받게 되며, 너무 많은 패킷을 보내려다가 둘 다 못보낼 수도 있다.

혼잡제어에 대한 접근법

우리는 네트워크 계층이 혼잡제어를 목적으로 트랜스포트 계층에게 어떤 직접적인 도움을 제공하는지에 따라 혼잡제어 접근을 구별할 수 있다.

종단간의 혼잡제어
- 혼잡제어에 대한 종단간의 접근법에서 네트워크 계층은 혼잡제어 목적을 위해 트랜스포트 계층에게 어떤 직접적인 지원도 제공하지 않는다.
- 네트워크에서 혼잡의 존재는 단지 관찰된 네트워크 행동에 기초하여 종단 시스템이 추측해야 한다. (예: 패킷 손실 및 지연)
- IP 계층이 네트워크 혼잡에 관해서 종단 시스템에게 어떠한 피드백도 제공하지 않으므로 TCP가 혼잡제어를 위한 종단간의 접근을 수행해야 한다.
- 타임아웃 또는 3중의 중복 확인에 의해 나타날 때, TCP 세그먼트 손실은 네트워크 혼잡의 발생으로 생각할 수 있으며 그에 따라 TCP는 윈도우 크기를 줄인다.
- TCP에 대한 새로운 제안으로 증가하는 RTT를 네트워크 혼잡 증가를 나타내는 것으로 사용하는 것이다.

네트워크 지원 혼잡제어
- 여기서 네트워크 계층 구성요소는 네트워크 안에서 혼잡상태와 관련하여 송신자에게 직접적인 피드백을 제공한다.
- 이 피드백은 링크의 혼잡을 나타내는 하나의 비트처럼 간단하다.
- 예를 들면, XCP 프로토콜은 라우터가 계산하여 피드백을 제공하는데, 라우터가 각각의 출발지에게 처리하는 패킷의 패킷 헤더 안에 어떻게 출발지의 전송률을 증가시키거나 감소시킬 것인지에 관한 정보를 넣어 보내는 것이다.

네트워크 지원 혼잡제어에 대한 혼잡 정보는 전형적인 두 가지 방법 중 하나로 네트워크에서 송신자에게 피드백된다.

직접 피드백
- 직접 피드백은 네트워크 라우터에서 송신자에게 보내는 것이다.
- 이 알림의 형태는 전형적으로 초크 패킷(choke packet)의 형태를 갖는다.
- 즉, “나는 혼잡하다!”라고 말하는 것이다.
수신자를 경유하는 네트워크 피드백
- 라우터가 혼잡을 나타내기 위해 송신자에서 수신자에게 흐르는 패킷 안의 특정 필드에 표시/수정하여 표시한다.
- 이 표시된 패킷을 수신했을 때, 수신자는 혼잡 상태를 송신자에게 알린다.
- 이 방법은 완전한 왕복시간이 걸린다는 점을 유의해야 한다.

TCP 혼잡제어

위에서 설명했듯이 IP 계층이 네트워크 혼잡에 관해서 종단 시스템에게 어떠한 직접적인 피드백을 제공하지 않으므로, TCP는 네트워크 지원 혼잡제어보다는 종단간의 혼잡제어를 사용해야 한다.

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

TCP 송신자가 혼잡을 감지하면 송신률을 줄이고, 없음을 감지하면 송신률을 높인다.

단, 이 방법은 세 가지 의문을 제기하는데, 1) TCP 송신자는 자신의 연결에 송신자 전송 트래픽 전송률을 어떻게 제한하는가?, 2) TCP 송신자는 자신과 목적지 사이 경로의 혼잡을 어떻게 감지하는가?, 3) 송신자는 종단간의 혼잡을 감지함에 따라 송신율을 변화시키기 위해서 어떤 알고리즘을 사용해야 하는가?이다.

먼저 TCP 송신자는 자신의 연결에 송신자 전송 트래픽 전송률을 어떻게 제한하는가?를 본다.

앞에서 TCP 연결의 양 끝 각 호스트들은 수신 버퍼, 송신 버퍼 그리고 몇 가지 변수를 설정하는 것을 보았다.

송신 측에서 동작하는 TCP 혼잡제어 메커니즘은 추가적인 변수인 혼잡 윈도우(congestion window, cwnd)를 기록한다.

cwnd는 TCP 송신자가 네트워크로 트래픽을 전송할 수 있는 비율을 제한하도록 한다.

특히 송신하는 쪽에서 확인응답이 안된 데이터의 양은 cwnd와 rwnd의 최솟값을 초과하지 않는다.: LastByteSent - LastByteAcked <= min {cwnd, rwnd}

그 다음 TCP 송신자는 자신과 목적지 사이 경로의 혼잡을 어떻게 감지하는가?이다.

타임아웃(TCP Tahoe) 또는 수신자로부터 3개의 중복 ACK(TCP Reno)들의 수신 이벤트가 발생했을 때, TCP 송신자 측에 “손실 이벤트(loss event)”가 발생했다고 정의한다.

과도한 혼잡이 발생하면, 경로에 있는 하나 이상의 라우터 버퍼들이 오버플로되고, 그 결과 데이터그램이 버려진다.

버려진 데이터그램은 송신 측에서 손실 이벤트를 발생시키고, 송신자는 송신자와 수신자 사이의 경로상의 혼잡이 발생했음을 알게 된다.

이제 어떻게 TCP 송신자가 자신이 송신할 속도를 결정하는가?에 대한 질문이다.

만약 전체 TCP 송신자들이 너무 빠르게 송신하게 되면 네트워크가 혼잡하게 되어 혼잡 붕괴가 나타날 것이고, 너무 천천히 송신한다면 네트워크 내의 밴드폭을 충분히 활용하지 못하게 된다.

즉, TCP 송신자들은 네트워크를 혼잡시키지 않고 더 높은 전송률로 보낼 수도 있는 것이다.

TCP는 아래의 원칙에 따른다.

손실된 세그먼트는 혼잡을 의미하며, 이에 따라 TCP 전송률은 한 세그먼트를 손실했을 때 줄어져야 한다.
확인응답된 세그먼트는 네트워크가 송신자의 세그먼트가 수신자에게 전송된다는 것이고, 이에 따라 이전에 확인응답되지 않은 세그먼트에 대해 ACK가 도착하면, 송신자의 전송률은 증가할 수 있다.
- ACK의 도착은 세그먼트들이 송신자에서 수신자로 성공적으로 전송되었고, 네트워크는 혼잡하지 않다는 묵시적 표시로 받아들여진다.
밴드폭 탐색
- ACK와 손실 이벤트가 있을 때, TCP는 TCP 송신자로 하여금 손실 이벤트가 발생할 때까지는 ACK가 도착함에 따라 전송률을 증가하는 것이고, 손실 이벤트가 발생한 시점에서 전송률을 줄이는 것이다.
- 즉, TCP 송신자는 혼잡이 발생하는 시점까지 전송률을 증가시키고(전송률을 탐색) 그 시점 이후부터는 줄여 나가고, 다시 혼잡 시작이 발생하는지를 보기 위한 탐색을 시작한다.
- 여기서 네트워크에 의한 혼잡 상태의 어떠한 명시적 신호가 없다는 것이고 ACK들과 손실 이벤트는 묵시적 신호이며 각 TCP 송신자들은 다른 송신자들과는 비동기적으로 로컬 정보에 근거해 동작한다.

이제 TCP 혼잡제어 알고리즘을 상세히 볼 것이다.

알고리즘은 세 가지 주요 구성요소들을 갖는다.

슬로 스타트 (slow start)
혼잡 회피 (congestion avoidance)
빠른 회복 (fast recovery)

슬로 스타트와 혼잡 회피는 TCP의 필수 요소이나, 수신된 ACK들에 대응하여 cwnd 크기를 얼마나 증가시키느냐는 것이 서로 다르다.

슬로 스타트는 혼잡 회피보다 더 빨리 cwnd 크기를 증가시키는 것을 보게 될 것이며, 빠른 회복은 권고되지만 TCP 송신자들에게는 필수 사항은 아니다.

슬로 스타트

TCP 연결이 시작될 때, cwnd의 값은 일반적으로 1MSS로 초기화되고, 그 결과 초기 전송률은 대략 MSS/RTT가 된다.

cwnd 값을 1MSS에서 시작하여 한 전송 세그먼트가 첫 번째로 확인응답을 받을 때마다 1 MSS씩 증가한다.

즉, 초기 cwnd = 1 MSS, 매 RTT마다 cwnd 값이 두 배로 증가하는 것이다.

그래서 TCP 전송률은 작은 값으로 시작하지만 슬로 스타트 단계 동안에 지수적으로 증가하게 된다.

이 지수적 증가는 언제 끝나는가? 슬로 스타트의 종료에 대한 3가지 답이 있다.

만약에 타임아웃(TCP Tahoe)에 의한 손실 이벤트(즉, 혼잡)가 있을 경우, TCP 송신자는 cwnd 값을 1로 하고, 새로운 슬로 스타트를 시작한다.
- TCP 송신자는 두 번째 상태 변수인 ssthresh(slow start threshold, 슬로 스타트 임계치의 약자) 값을 cwnd/2(혼잡이 검출 되었을 시점에서의 혼잡 윈도우 값의 반)으로 정한다.

ssthresh 값은 혼잡이 마지막 검출된 시점에서의 cwnd 값의 반으로, cwnd 값이 ssthresh과 같으면, 슬로 스타트는 종료되고 TCP는 혼잡 회피 모드로 전환한다.
- TCP는 혼잡 회피 모드에서 cwnd를 좀 더 조심스럽게 증가시킨다.

3개의 중복 ACK(TCP Reno)들이 검출되면, TCP는 빠른 재전송을 수행하여 빠른 회복 상태로 들어간다.

아래는 TCP 혼잡제어의 FSM이다.

혼잡 회피

혼잡 회피 상태로 들어가는 시점에서 cwnd 값은 대략 혼잡이 마지막 발견된 시점에서의 값의 반으로 된다.

그러므로 매 RTT마다 cwnd 값을 두 배로 하기보다는 TCP는 좀 더 보수적인 접근법을 채택하여 매 RTT마다 하나의 MSS만큼 cwnd 값을 증가시킨다.

즉, 매 RTT마다 1 MSS만큼 cwnd 값이 증가한다.

예를 들면, MSS가 1460바이트이고 cwnd가 14600바이트일 때, 10개의 세그먼트를 한 RTT 내에 송신할 수 있다.

이에 따라 모든 10개의 세그먼트가 수신되었을 때의 ACK들 후에 하나의 MSS만큼만 혼잡 윈도우 값을 증가한다.

그럼 언제 혼잡 회피의 선형 증가가 끝나는가?

TCP 혼잡 회피 알고리즘은 타임아웃이 발생했을 때와 같이 동작한다.

슬로 스타트의 경우에서와 같이, cwnd 값은 1로 설정하고, ssthresh의 값은 손실 이벤트가 발생할 때의 cwnd 값의 반으로 설정한다.

3개의 중복 ACK 수신의 경우, TCP는 cwnd의 값을 반으로 하고 ssthresh 값을 3개의 중복 ACK들을 수신한 시점에서의 cwnd값의 반으로 한다.

이후 빠른 회복 상태로 들어간다.

빠른 회복

빠른회복에서 cwnd 값은 잃었던 세그먼트에 대한 매 중복된 ACK를 수신할 때마다 1 MSS만큼씩 증가된다.

만약 타임아웃 이벤트가 발생하면 빠른 회복은 슬로 스타트와 혼잡 회피에서와 같은 동작을 수행한 후 슬로 스타트로 전이한다.

즉, cwnd 값은 1 MSS로하고, ssthresh값은 손실 이벤트가 발생할 때의 cwnd 값의 반으로 한다.

초기 TCP는 TCP Tahoe라 부르는데 이 땐 타임아웃 또는 3개의 중복 ACK 등의 손실 이벤트가 발생하면 무조건 혼잡 윈도우를 1 MSS로 줄이고, 슬로 스타트 단계로 들어간다.

새로운 TCP 버전인 TCP Reno는 빠른 회복을 채택하였다.

위의 그림으로 보면 임계치는 초기에는 두 가지 모두 8 MSS이다.

처음 8번의 전송 동안은 Tahoe와 Reno는 동일한 행동을 취한다.

cwnd는 슬로 스타트 동안 지수적인 증가를 하고, cwnd 값이 ssthresh에 도달했을 때 혼잡 회피로 전환되고 매 RTT당 1 MSS 씩 선형적으로 증가를 한다.

그러다가 8번째 송신 후에 3개의 중복 ACK가 발생하게 되는데, 우선 임계치 값은 손실 발생 시점 cwnd 값이 12 MSS이므로 절반의 값인 6 MSS로 ssthresh 값이 설정된다.

이 시점에서 Tahoe는 무조건 cwnd를 1 MSS로 줄이고, 슬로 스타트 단계에 들어가므로 ssthresh 값까지 지수적인 증가를 한 뒤 cwnd >= ssthresh 부터는 선형적인 증가를 하는 걸 볼 수 있다.

TCP Reno는 빠른회복 상태로 들어가므로 혼잡 회피에서 3개의 중복 ACK에 의해 빠른 회복 상태로 들어갈 때, cwnd의 값과 ssthresh 값은 절반이 되므로 cwnd 값은 6 MSS가 된다.

따라서 표에서와 같이 TCP Reno는 손실 이벤트 이후 6 MSS에서 시작하는 걸 볼 수 있으며 선형적으로 증가하는 걸 볼 수 있다.

TCP 혼잡제어: 복습

TCP 혼잡제어는 손실 발생 전까지 RTT마다 1 MSS씩 증가하나 손실 발생 시 절반으로 줄어든다.

이러한 이유로 TCP 혼잡제어는 AIMD(Addictive Increase, Multiplicative Decrease)라고 불린다.

TCP는 3개의 중복 ACK 이벤트 전까지 선형으로 cwnd가 증가하고, 이벤트가 발생하면 절반으로 감소시키지만, 다시 추가적인 가용한 밴드폭이 있는지를 탐색하기 위해 선형으로 증가하기 시작한다.

공평성

위의 사진처럼 전송률 R을 갖는 하나의 링크를 공유하는 2개의 TCP 연결의 간단한 경우를 고려해 본다.

두 연결이 같은 MSS와 RTT를 갖는다고 가정하고 그들은 송신하기 위한 큰 양의 데이터를 갖고 있고, 어떠한 다른 TCP 연결이나 UDP 데이터그램도 이 공유된 링크를 통과하지 않는다고 가정한다.

위의 사진이 2개의 TCP 연결에 의해 실현되는 처리율을 나타낸 것이다.

만약 TCP가 두 연결 사이에서 링크 대역폭을 똑같이 공유한다면, 실제 처리율은 동등한 대역폭 공유를 따라야 한다.

이상적으로 두 처리율의 합이 R과 같아야 한다.

목적은 “동등한 대역폭 공유” 선과 “전체 대역폭 이용”선의 교차 지점 가까운 곳의 처리율을 얻도록 하는 것이다.

TCP 윈도우 크기가 연결 1과 2가 A 지점으로 나타내는 처리율을 실현한다고 가정한다.

두 연결에 의해 공동으로 소비되는 링크 대역폭의 양이 R보다 작으므로, 어떠한 손실도 발생하지 않을 것이다.

그리고 양 연결은 TCP 혼잡 회피 알고리즘에 의해 RTT당 1 MSS씩 윈도우를 증가시키므로 점점 B 지점으로 가게 되어, 링크 대역폭이 R보다 커질 것이고 패킷 손실이 발생한다.

이제 B 지점에서 처리율을 실현할 때, 패킷 손실이 발생하므로 윈도우 크기를 감소시킬 것이다.

따라서 C로 이동하게 되고, 이를 반복하게 된다.

즉, 결론적으로 손실이 발생하지 않으면 윈도우를 증가시키고, 손실이 발생하면 윈도우를 감소시키는걸 반복하게 되는데, 두 연결에 의해 실현되는 대역폭이 똑같은 대역폭 공유선을 따라서 결국에는 변동하고 수렴하게 된다는 것이다.

공평성과 UDP

많은 멀티 미디어는 네트워트가 혼잡하더라도 자신의 전송률이 조절되는 것을 원하지 않는다.

대신에 이들 애플리케이션은 오히려 혼잡제어를 가지고 있지 않은 UDP상에서 동작하는 것을 좋아한다.

UDP상에서 동작할 때, 애플리케이션은 혼잡할 때 “공평한” 레벨로 그들의 등급을 낮추고 어떠한 패킷도 손실하지 않기보다는 일정한 속도로 네트워크에 오디오와 비디오를 공급하기를 좋아하고 가끔 패킷을 손실한다.

TCP의 관점에서 보면 UDP는 공평하지 못하는데, 다른 연결들과 협력하지도 않으며 그들의 전송률을 적당하게 조절하지도 않는다.

TCP는 혼잡제어로 전송률을 감소시키고, UDP는 그렇지 않으므로 TCP 트래픽을 밀어낼 가능성이 있다.

오늘 날 연구의 주요 분야는 UDP 트래픽으로 인해 인터넷이 마비되는 것을 방지하는 인터넷을 위한 혼잡제어 방식을 개발하는 것이다.

명시적 혼잡 표시

TCP는 네트워크 계층으로부터 어떠한 명시적인 혼잡 정보를 받지 않고, 대신 패킷 손실로부터 혼잡을 추측할 뿐이다.

최근에는 네트워크가 명시적으로 TCP 송신자와 수신자에게 혼잡을 알리는 IP와 TCP의 확장(RFC 3168)이 제안되고, 구현 및 구축되었다.

이러한 네트워크-지원 혼잡제어의 형식을 명시적 혼잡 표시 (ECN, Explicit Congestion Notification)라고 알려져 있다.

네트워크 계층에서는, IP 데이터그램 헤더의 서비스 형식 필드 내에 두 비트가 ECN에 사용된다.

ECN 비트들의 세팅 중에 하나는 라우터에 의해 사용되는데 라우터가 경험하는 혼잡을 표시한다.

이 혼잡 표시는 표시된 IP 데이터그램에 의해 목적지 호스트로 전송되고, 이 목적지 호스트가 이를 송신 호스트에게 알려주는 것이다.

아래는 그 과정이다.

RFC 3168은 언제 라우터가 혼잡되는 가를 정의하지 않고, 그 결정을 네트워크 운용자가 결정하도록 하였으며, RFC 3168은 ECN 혼잡 표시는 지속적인 혼잡의 경우에만 세팅되도록 권고하고 있다.

두 번째 ECN 비트의 세팅은 송신 호스트에서 사용하여 라우터에게 송신자와 수신자가 ECN-가용하다는 것을 알림으로써, ECN에 대응한 행동을 취할 수 있음을 알리는 것이다.

위의 그림을 보면 수신 호스트의 TCP가 수신된 데이터그램을 통하여 ECN 혼잡 표시를 수신하면, 수신 호스트의 TCP는 송신 호스트의 TCP에게 ECE (ECN echo) 비트를 세팅함으로써 혼잡 표시를 알려준다.

ECE 비트는 수신자에서 송신자로 가는 TCP ACK 세그먼트에서 정의된다.

이에 대해, ECE 혼잡표시를 갖는 ACK를 받은 송신 TCP는 혼잡 윈도우를 반으로 줄이게 된다.

사진 인용

Link: justlog.tistory.com/m/8 - RDT Protocol; justlog.tistory.com/m/11 - GBN & Selective repeat; justlog.tistory.com/m/15 - TCP; velog.io/@tonyhan18/series/21-기초컴퓨터네트워크; cnsr.dev/index_files/Classes/Networking/Content/03-Transport.html; icode9.com/content-4-974173.html