요약
- RFC 3366는 링크 계층 ARQ의 지속 재전송을 신뢰성을 공짜로 높이는 수단이 아니라, 링크가 포기를 결정하기 전에 한 프레임 복구에 어느 만큼의 시간을 쓸지에 대한 한정된 결정으로 다루었습니다.
- 한 번의 재시도는 한 전송 계층 플로우에는 도움이 되지만, 다른 트래픽에는 누적 지연·지터·막힘을 더할 수 있으며, 프레임 확인 응답은 적시의 애플리케이션 전달을 증명하지 못합니다.
프레임은 패킷 전체가 아니다
이야기는 IP 아래에서 시작됩니다. 자동 재전송 요청(ARQ)은 유실되거나 손상된 링크 프레임을 감지하고 다시 시도합니다. 링크에 따라 한 프레임은 IP 패킷의 일부 조각, 패킷 전체, 또는 둘 이상의 패킷 조각을 실을 수 있습니다. 링크의 확인 응답이 답하는 질문은 좁습니다. 이 프레임이 그 링크 프로토콜에서 수용되었는가? 이는 종단 간 패킷이 목적지에 도달했는지, 애플리케이션이 여전히 그것을 쓸 수 있는지를 보증하지 않습니다.
2002년 8월 Best Current Practice 62로 발표된 RFC 3366은 설계자에게 이 경계를 진지하게 다루라고 요청했습니다. 저자들은 특정 무선 프로토콜을 규정하거나 재시도 횟수를 하나로 정한 것이 아니었습니다. 링크 고유의 복구 루프가 그 위의 인터넷 트래픽과 어떻게 상호작용하는지 설명한 것입니다.
재시도 예산은 공유된 시간을 쓴다
이 문서는 재시도 의지를 "지속성(persistence)"이라고 부릅니다. 설계는 고정된 시도 횟수를 허용할 수도 있고, 타이머와 링크 장애 절차가 재전송 중단 시점을 결정하게 할 수도 있습니다. 시도 횟수는 곧 시계가 아닙니다. 전파 지연, 공유 매체 백오프, 큐잉, 프레임 크기, 처리 시간이 모두 경과 시간에 영향을 줍니다.
그래서 신뢰성은 조건부가 됩니다. 로컬 링크는 종종 TCP의 종단 간 제어 루프보다 빠르게 반응해 발신자가 재전송하기 전에 채널 오류를 복구할 수 있습니다. 그러나 복구된 프레임이 도착할 때에는 전송 계층 타이머 동작을 바꿀 만큼 지연이 쌓였을 수 있습니다. 링크가 패킷을 순서대로 보관한다면, 뒤의 완전한 패킷들은 아직 재시도 중인 한 프레임 뒤에서 기다려야 합니다. 공유 채널에서는 재시도가 다른 노드에 필요한 무선 시간을 소모할 수도 있습니다.
완전한 지속성은 이 대비를 선명하게 드러냅니다. 끝없이 계속 시도하되, 수신자가 여전히 수용할 수 있는 동안에는 링크 패킷을 유실로 보고하지 않는 것입니다. 신뢰성 있는 전달이 목적인 전송에는 유용할 수 있습니다. 그러나 여러 링크에 걸친 경우, 반복된 복구는 이미 종단 간에서 제공되는 작업을 중복 수행하며, 종단점의 전송 계층과 같은 신뢰성을 보장할 수 없습니다. 스트리밍 등 시간에 민감한 UDP 트래픽에서는 늦게 도착한 패킷이 없는 패킷보다 덜 쓸모 있을 수 있습니다.
링크가 안전하게 알 수 있는 것
"신뢰성 있어 보이는" 트래픽에 긴 지속성을, 나머지에는 짧은 지속성을 부여하고 싶은 유혹이 있습니다. RFC 3366은 관찰만으로는 부족하다고 설명합니다. 링크는 혼잡 제어 동작을 볼 수 있어도 애플리케이션의 기한이나 완전성보다 적시성을 중시하는지는 알 수 없습니다. 포트 번호는 오해를 일으키거나 재매핑될 수 있고, 터널은 서로 다른 플로우를 합치며, 암호화된 페이로드는 검사를 제한하고, 서비스 마킹은 덮어쓰이거나 국소적 의미만 가질 수 있습니다.
따라서 권고는 조건부입니다. 설계자가 서비스 클래스를 안전하게 구분할 수 있다면 서로 다른 재시도 동작이 도움이 될 수 있습니다. 그렇지 않다면 모든 플로우는 같은 링크 동작을 물려받습니다. 구분이 불가능한 링크에서는 이 BCP가 일반적으로 낮은 지속성을 선호합니다. 일부 프레임은 복구하되, 미완료 패킷 하나가 큐를 무기한 붙잡지 않도록 하는 것입니다. 문서는 반례도 남겨 둡니다. 높은 지속성은 일부 가변 오류 또는 장애 후 조건에서 TCP 플로우에 도움이 될 수 있습니다. 만능의 최적 설정은 없습니다.
2004년에 발표된 더 포괄적인 서브네트워크 설계 BCP인 RFC 3819는 이 그림을 유실, 평균 지연, 지연 편차 사이의 삼각 긴장으로 넓혔습니다. 이후의 가이드는 유연성을 강화할 뿐, 2002년의 2~5회 재시도 예시를 현대의 규칙으로 만들거나 실제 네트워크 배포를 측정한 것으로 바꾸지 않습니다.
영수증은 국소에 머문다
RFC 3366의 오래가는 교훈은 성능만큼이나 증거에 관한 것입니다. 프레임 ACK는 한 국소 이벤트를 기록합니다. 패킷이 링크를 떠나는 것, 전송 계층이 데이터를 수용하는 것, 애플리케이션이 제시간에 받는 것은 이후의 이벤트이며 각각 자신의 증거가 필요합니다. 재시도는 채널 오류 유실을 줄이는 동시에 지터를 악화시키고, 혼잡 피드백을 지연시키고, 다른 플로우에 필요한 시간을 소모할 수 있습니다.
링크 설계자는 국소 예산을 선택하고, 경로는 그 결과를 누적합니다. 경로의 나머지 부분이나 애플리케이션의 신선도 요구를 모르는 상태에서, 장치는 "더 많은 시도"를 더 나은 서비스의 약속으로 바꿀 수 없습니다. BCP 62는 링크 설계자에게 이 불확실성을 설계의 일부로 만들라고 요청했으며, 신뢰성이라는 라벨 아래에 숨기라고 하지 않았습니다.
출처
- RFC 3366 / BCP 62 — 링크 설계자를 위한 링크 ARQ 관련 조언
- RFC 3366 메타데이터 및 발표 현황
- RFC 3366의 IETF Datatracker 기록
- RFC 3819 — 인터넷 서브네트워크 설계자를 위한 조언
- RFC 3155 — 손실이 많은 링크에서의 종단 간 TCP 동작
- RFC 3135 — 성능 향상 프록시
- RFC 5681 — TCP 혼잡 제어
- RFC 6298 — TCP 재전송 타이머 계산
- RFC 8985 — RACK-TLP 유실 감지
- RFC 2475 — 차등화 서비스(Differentiated Services) 아키텍처
- RFC 3260 — Diffserv 용어 및 명확화
- RFC 2406 — IPsec 캡슐화 보안 페이로드
- RFC 3022 — 전통적 IP 네트워크 주소 변환기
- RFC 3935 — IETF의 사명 선언문
- Lu Heng, "Running-Code Primacy"
- Lu Heng, "Reality Layers"
Lu Heng은 RFC 3366의 저자가 아닙니다. 이 글들은 권고, 실행 중인 구현, 구성된 동작, 관찰된 결과 사이의 차이를 분석하는 관점으로 공개된 것입니다.
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





