요약
- RFC 3155는 관찰된 신호와 그 실제 원인을 구분했습니다. 중복 ACK, 시퀀스 구멍 또는 타이머 만료는 신중한 대응을 정당했지만, 혼잡이나 전송 오류, 재정렬, 역방향 경로 손실을 증명하지는 않았습니다.
- Fast Retransmit/Fast Recovery, SACK, D-SACK, NewReno는 혼잡 제어를 유지하면서 복구를 개선했습니다. 이들은 도착과 복구를 서술했을 뿐, 사라진 세그먼트의 위치나 메커니즘은 설명하지 않았습니다.
- 완전한 증명은 링크, 큐, 양방향 경로, 윈도우 상태, 재전송, 재조립, 응용 결과를 연결해야 합니다. 정렬된 바이트 스트림의 도착만으로 서비스 성공을 증명할 수는 없습니다.
윈도우는 자신이 이름 붙일 수 없는 위험을 기억하고 있었다
TCP의 혼잡 제어는 손실을 진지하게 다루는 법을 배웠습니다. 확인 응답이 더 이상 앞으로 나아가지 않으면 송신자는 야심을 줄였습니다. 이 동작은 라우터 큐의 직접 측정이 아니었습니다. 평범한 손실이 주로 혼잡에서 비롯되던 인터넷을 위해 만들어진 안전 규칙이었습니다.
접속의 확대는 경로의 구성을 바꾸고 있었습니다. 무선 지상 회선, 위성, 그 밖의 불완전한 링크에서는 교정되지 않은 오류가 전송 계층까지 도달하기도 했습니다. 패킷은 손상된 뒤 TCP에 도달하기 전에 폐기될 수 있었습니다. 로컬 복구가 지연과 재정렬을 일으킬 수 있었습니다. ACK가 되돌아오는 길에서 사라질 수 있었습니다. 경로 변경은 도착 순서를 바꿀 수 있었습니다. 물론 꽉 찬 큐도 같은 세그먼트를 버릴 수 있었습니다.
송신자의 관점에서 이 이야기들은 서로 겹쳤습니다. 다음 기대 번호는 앞으로 나아가지 않았고, 동일한 ACK들이 돌아오거나 타이머가 만료되었습니다. RFC 3155는 당시 연구된 종단 간 휴리스틱이 혼잡과 데이터 손상을 안전하게 구분하는 데 실패했다는 점을 상기시켰습니다.
이 무지가 대응을 무의미하게 만들지는 않았습니다. 다만 대응의 범위를 정했습니다. 윈도우 축소는 제어 규칙이 실행되었음을 증명할 뿐, 손실의 물리적 원인을 증명하지 않았습니다.
신중함으로 틀리는 데에는 비용이, 반대로 틀리는 데에는 더 큰 비용이 있었다
무선 오류를 혼잡으로 착각하면 아마도 이용 가능한 경로를 과소 사용하게 됩니다. 송신자는 윈도우를 줄이고 재전송한 뒤, 큐가 문제가 아니었음에도 천천히 다시 올라갑니다.
반대로 혼잡을 단순한 전송 오류로 착각하면 모두의 상황을 악화시킬 수 있습니다. 같은 속도로 계속 주입하면 큐를 더 채우고 폐기를 늘리며 안정성을 위협합니다. 그래서 RFC 3155는 우선순위를 유지했습니다. 원인에 대한 신뢰할 수 있는 피드백이 없다면, 가장 빠른 복구보다 혼잡 예방이 우선해야 했습니다.
이는 모든 손실이 곧 혼잡이라는 형이상학적 선언이 아니라 제어의 비대칭이었습니다. 공유 네트워크가 집단적 위험을 감당했고, 송신자는 모든 것을 알기 전에 행동해야 했습니다.
감사 관점에서 이 미묘한 차이는 결정적입니다. 시간적으로 가까운 링크 오류 카운터는 가설을 강화하지만, 방향과 흐름, 시퀀스 번호, 공통 시계에까지 연결해야 합니다.cwnd감소는 TCP의 대응을 보여줄 뿐, 어떤 버퍼도 특정하지 않습니다.
하나의 공식은 패킷을 식별하지 않고도 문제의 범위를 한정할 수 있었다
이 문서는 세그먼트 크기, 종단 간 RTT, 재전송 타이머, 정상 상태 손실 확률로부터 TCP Reno의 처리량을 근사하는 공식을 인용했습니다. 이 계산은 관찰된 손실률에서 TCP의 대응이 이미 처리량을 링크 용량 이하로 제한하는지 묻기 위한 것이었습니다.
주의 사항은 도구의 일부였습니다. RTT는 의심되는 링크만의 값이 아니었습니다.Max(1.0, 4*RTT)는 RTO를 대신하는 단순화된 치환일 뿐이었습니다. 손실 평균은 버스트를 가릴 수 있었는데, 바로 그 버스트가 한 윈도우 안의 여러 세그먼트를 없애곤 했습니다.
모델이 링크 속도보다 높은 처리량을 예측한다면 TCP 복구는 그 물리적 한계를 넘을 수 없습니다. 예측 처리량이 낮게 남아 있고 조사가 상당한 전송 오류를 확인한다면, 권고된 메커니즘들이 이용 가능한 용량을 더 잘 활용할 수 있었습니다.
공식은 라우터도, 비트도, 사건의 원인도 드러내지 않았습니다. 조사의 임계선을 세울 뿐이었습니다. 측정된 입력, 가정, 실제 구현은 여전히 분리된 조각들이었습니다.
세 개의 중복 ACK는 기다림을 피했지만 확실성을 만들지 않았다
수신자가 구멍 뒤에 놓인 세그먼트를 받으면, 다음 기대 바이트 번호를 즉시 반복해서 보냅니다. 세 개의 중복 ACK가 모이면 Fast Retransmit은 송신자가 RTO가 완전히 만료되기를 기다리지 않고 잃어버린 것으로 추정되는 세그먼트를 다시 보낼 수 있게 합니다.
Fast Recovery는 윈도우를 절반으로 줄이고 혼잡 회피 상태로 진행합니다. 타임아웃은 반대로 훨씬 작은 윈도우로 Slow Start로 되돌아갑니다. 중복 ACK는 일부 트래픽이 여전히 경로를 통과하고 있음을 나타내므로, 덜 엄격한 복구를 허용합니다.
그러나 중복 ACK는 여전히 구멍을 설명하지 않습니다. 링크 재전송 뒤의 늦은 도착, IP 재정렬, 경로 변경도 같은 ACK를 만들 수 있습니다. 세 개라는 임계값은 혼잡 센서가 아니라 운영상의 트리거였습니다.
윈도우가 가법적 복원을 마치기 전의 반복 손실은 RFC 3155가 기술한 '하강 나선'을 만들 수 있었습니다. 매번 절반으로 줄이는 조치는 이미 줄어든 윈도우를 다시 때렸습니다. 끊임없이 나쁜 링크에서는 윈도우가 그저 오랫동안 작은 채로 남을 수 있었습니다.
세그먼트 4개 이하에서는 Fast Retransmit에 필요한 세 개의 ACK를 만들 데이터가 부족할 수도 있었습니다. 그러나 작은 윈도우가 항상 열악한 링크의 서명은 아니었습니다. 짧은 HTTP 연결은 단련된 TCP를 계속 닫고 Slow Start의 새 연결을 열었습니다.
SACK는 도착을 지도로 그렸을 뿐, 구멍의 범인을 말하지 않았다
누적 ACK는 연속된 경계를 알려줍니다. 한 윈도우 안에 여러 세그먼트가 빠져 있으면 이 경계는 구멍 너머로 이미 받은 블록을 잘 설명하지 못합니다. SACK는 수신자가 이런 블록을 알리고, 송신자가 왕복마다 하나씩 발견하는 대신 여러 결손을 한꺼번에 복구하게 합니다.
RFC 3155는 RFC 2883의 D-SACK 확장과 함께 SACK를 권고했습니다. D-SACK는 중복에 대한 단서를 추가하여 재정렬, ACK 손실, 패킷 복제, 너무 이른 재전송에 대처하는 데 유용했습니다. 긴 RTT 환경이나 큰 윈도우 한가운데의 오류 버스트에서 이 정보는 시간과 불필요한 전송을 아꼈습니다.
이 지도는 여전히 도착의 지도였습니다. 두 구간이 수신되었고 세 번째가 빠져 있다고 말할 수는 있었습니다. 하지만 세 번째가 어떤 큐, 잡음, 다른 고리의 고장을 만났는지는 말하지 않았습니다.
양쪽 끝에서 SACK를 켤 수 없을 때는 NewReno가 부분 ACK와 다중 손실 처리를 개선했습니다. Limited Transmit은 작은 윈도우가 충분한 중복 ACK를 만들도록 돕고자 했습니다. RFC 3155는 이를 보편적 결과의 증거가 아니라 평가해야 할 작업으로 분류했습니다.
이 도구들은 복구 부채를 줄였습니다. 그중 어느 것도 혼잡을 무시할 허가를 주지 않았습니다.
패킷 크기는 여러 메커니즘을 동시에 바꿨다
신뢰성이 낮은 링크는 종종 줄인 MTU를 사용했습니다. 윈도우는 세그먼트 단위로 열리기 때문에 작은 세그먼트는 그 성장을 느리게 만들 수 있었습니다. 그러나 MTU 축소만으로는 어떤 오류도 고쳐지지 않았습니다.
경로 MTU 발견은 단편화를 피하고 지원되는 가장 큰 단위를 쓰게 해 줍니다. 불필요하게 작은 선택보다 열림을 빠르게 할 수 있지만, 지연-대역폭 곱에 도달하려면 여러 RTT가 여전히 필요할 수 있었습니다.
이 항목은 RFC 3150의 중심 메커니즘을 다시 다루지 않았습니다. RFC 3150은 큰 패킷이 느린 공유 링크를 차지하는 시간을 다뤘습니다. RFC 3155는 잔여 손실이 TCP의 해석과 복구에 미치는 영향을 다뤘습니다. 한 왕복의 시간과 신호의 모호함은 같은 증거가 아닙니다.
더 작은 패킷은 직렬화, 헤더 비중, 윈도우당 세그먼트 수, 단편화, 오류 노출을 모두 바꿉니다. 단순히 '작을수록 신뢰하다'라고 말하면 이 상반된 관계들을 뭉개버립니다.
양끝에 머무르는 것은 암호화를 지키고 시야를 제한했다
채택된 권고 사항은 TCP를 이해하는 중간 노드를 요구하지 않았습니다. 따라서 종단 간 IPsec과도 계속 작동하며 양 끝 간의 운명 공유를 유지했습니다. 그 대가는 끝점 사이에서 일어나는 국소 사건에 대한 무지였습니다.
경계에 놓인 성능 향상 프록시(PEP)는 특수한 특성을 관찰할 수 있었습니다. 그러나 PEP는 세 번째 고장 지점, 이동성에서 옮겨야 할 상태, 대칭 경로에 대한 의존, 확장성과 진단 문제, 그리고 흔히 종단 간 보호와의 비호환을 추가했습니다. 모든 PEP가 모든 결함을 갖는 것은 아니었고, 결정에는 정밀한 검토가 필요했습니다.
RFC 3155는 RFC 3135가 다룬 PEP의 전체 역사를 다시 서술하지 않았습니다. 자신의 선택의 한계를 정하는 데 그것을 활용했습니다. 더 나은 국소 가시성은 중간자가 연결을 더 많이 소유해야 가능했습니다. 양 끝은 호환성을 유지하면서 모든 것을 알지 못하는 것을 받아들였습니다.
ECN은 혼잡을 알렸지, 전송 오류를 알리지 않았다
ECN은 패킷 폐기 이전에 혼잡에 대한 명시적 피드백을 제안했습니다. 호환되는 TCP와 표식을 보존하는 경로에서는 이 신호가 혼잡에 대한 지식을 개선했습니다.
RFC 3155는 그 반대를 유추하는 것을 거부했습니다. ECN은 명시적 전송 오류 통지로 전용될 수 없었습니다. 표식 없는 손실은 감산으로 증명된 손상이 되지 않았습니다. 헤더 자체가 손상되면 네트워크는 통지를 어느 끝점에 보내야 하는지조차 모를 수 있었습니다.
이 문서는 미래를 위해 더 나은 오류 신호를 희망했지만 그것을 규격화하지는 않았습니다. 한 신호의 부재가 다른 신호의 내용이 되지는 않았습니다.
권고 사항은 연구 과제보다 적었다
권고의 핵심은 몇 가지 결정으로 요약되었습니다. Slow Start와 Congestion Avoidance를 약화시키지 않는다. Fast Retransmit/Fast Recovery를 배치한다. SACK와 D-SACK를 사용한다. 양쪽 끝에서 SACK를 쓸 수 없을 때는 NewReno로 다중 손실 처리를 개선한다.
다른 제안들은 열려 있었습니다. 중복 ACK를 지연시키면 링크 복구가 끝나기를 기다릴 수 있지만, 모든 토폴로지에 안전한 지연 값은 없었습니다. 송신 페이싱과 ACK 리듬 제어는 버스트를 줄일 수 있었습니다. Appropriate Byte Counting은 실제 수신된 바이트에 따라 윈도우를 키울 수 있었지만, ACK 손실 뒤의 버스트를 키울 위험도 있었습니다.
응용도 이 이야기에 참여했습니다. HTTP 지속 연결은 경로 학습을 유지했습니다. RFC 2140과 Congestion Manager는 연결 간 정보 공유를 탐색해, 매 전송이 완전한 무지에서 시작하지 않도록 했습니다.
'향후 작업' 항목은 완성된 표준도, 구현도, 이득도 보증하지 않았습니다. 양쪽 끝이 옵션을 협상했다는 사실만으로도 코드가 조사 대상 손실 시점에 그것을 올바르게 행사했음을 증명하지는 못했습니다.
복구된 흐름이 경험한 지연을 지우지는 않았다
TCP는 정렬된 스트림을 전달해야 합니다. 구멍이 남아 있는 동안 수신자는 이후 바이트들을 응용에 넘기지 않고 보관할 수 있습니다. 구멍을 메우는 재전송은 재조립을 전진시킵니다. 이 전송 계층의 성공은 실제입니다.
그러나 그것은 여전히 원인을 밝히지 않고, 서비스의 성공을 보장하지도 않습니다. 트랜잭션은 기한이 지난 뒤에 끝날 수 있습니다. 사용자는 복구 전에 포기할 수 있습니다. 전송은 끝까지 도달하면서도 가용 용량보다 훨씬 낮은 속도로 오래 머물 수 있습니다.
따라서 기록은 응용과 경로의 맥락, RTT·RTO·MSS·윈도우·ACK, 구멍과 타이머, 큐와 ECN 표식, 링크 오류·복구·재정렬, 선택된 알고리즘, 재전송과 윈도우 궤적, 재조립, 마지막으로 응용의 시각과 결과를 함께 보존해야 합니다.
RFC 3155의 교훈은 속도를 줄이는 일을 그만두라는 것이 아니었습니다. 진단이 불완전하게 남아 있어도 안전 결정은 옳을 수 있습니다. TCP는 가용한 정보로 공동의 이익을 지켰습니다. 조사는 여전히 손실을 설명하고 복구의 가치를 측정해야 했습니다.
출처
- RFC 3155 텍스트
- RFC 3155 정보 페이지
- RFC 3155 HTML
- RFC 3155 문서 이력
- RFC 793 — Transmission Control Protocol
- RFC 1122 — 인터넷 호스트 요구사항
- RFC 1191 — 경로 MTU 발견
- RFC 1323 — 고성능을 위한 TCP 확장
- RFC 2018 — Selective Acknowledgment 옵션
- RFC 2140 — TCP 제어 블록의 상호 의존
- RFC 2481 — 명시적 혼잡 통지
- RFC 2488 — 위성 채널에서의 TCP 개선
- RFC 2581 — TCP 혼잡 제어
- RFC 2582 — NewReno 수정
- RFC 2861 — 혼잡 윈도우 검증
- RFC 2883 — SACK 옵션 확장
- RFC 3042 — Limited Transmit
- RFC 3124 — Congestion Manager
- RFC 3135 — Performance Enhancing Proxies
- Running-Code Primacy
- On Reality Layers
- Minimum Initial Specification
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





