요약

  • RFC 3124는 애플리케이션이 호스트 전역 혼잡 관리자(Congestion Manager)에 전송 기회를 요청할 수 있게 했지만, 요청에는 애플리케이션 버퍼가 담기지 않았고 콜백은 일반적으로 경로 MTU까지의 유한한 전송 권한만 부여했습니다.
  • 그랜트는 큐에 등록된 패킷도, 강제된 예약도, 전달 확인증도 아니었습니다. 애플리케이션이 콘텐츠를 선택하고 필요하면 재패킷화했으며, 실제 송출된 바이트 수를cm_notify로 보고하고, 수신자 피드백은 별도로cm_update로 제공했습니다.

한 호스트는 혼잡 교훈을 너무 많이 배웠다

2000년 전후 인터넷 호스트는 동일 목적지로 여러 흐름을 동시에 실행하면서도 각 애플리케이션이 혼잡 상황을 따로 학습했습니다. 브라우저는 병렬 전송을 열었고, 오디오·비디오 프로그램은 각자 속도를 조절했습니다. 같은 기기의 다른 연결이 최근에 같은 경로를 측정했더라도 새 세션은 거의 아무 지식 없이 반복해서 시작되었습니다. 결과는 단순한 중복 작업에 그치지 않았습니다. 독립적인 제어 루프들이 서로 경쟁하고, 나쁘게 시작하며, 하나의 병목 지점에 대해 서로 다른 시각을 애플리케이션에 노출할 수 있었습니다.

RFC 2140은 이미 동일 호스트로의 연결 간에 선택된 TCP 제어 블록 상태를 공유하는 방식을 기술한 바 있었습니다. 2001년 6월 Standards Track으로 발표된 RFC 3124는 이 경계를 더 앞으로 옮겼습니다. 문서의 혼잡 관리자, 즉 CM은 관련 흐름들을 하나의 매크로플로우로 묶고 그에 대한 혼잡 상태를 유지하는 단말 시스템 모듈이었습니다. 애플리케이션은 비동기 인터페이스로 전송 허가를 요청하거나, 동기 인터페이스로 속도와 혼잡 추정치를 조회하면서 자체 스케줄링을 수행할 수 있었습니다.

이 변화는 구조적이었습니다. 모든 애플리케이션이 무엇을 언제 보낼지 각자 결정하는 대신, 공통 서비스가 희소한 전송 기회를 조정할 수 있게 된 것입니다. 그러나 RFC 3124는 그 공통 서비스를 범용 패킷 큐로 만들지 않았습니다. 이 구분이 설계의 핵심입니다.

요청에는 의도적으로 데이터가 없었다

애플리케이션은 보낼 데이터가 있을 때cm_request를 호출했습니다. 이 호출은 버퍼를 혼잡 관리자에 넘기지 않았습니다. 따라서 CM은 애플리케이션의 패킷을 저장하거나 페이로드를 검사하거나 특정 메시지가 나중에 나갈 것을 약속하지 않았습니다. CM이 기록한 것은 기회에 대한 수요였습니다.

혼잡 제어기와 스케줄러가 전송을 허용하면 CM은cmapp_send콜백을 호출했습니다. 콜백은 애플리케이션에 지정된 최대치, 보통 하나의 경로 최대 전송 단위까지 전송할 권한을 부여했습니다. 그 시점에 애플리케이션은 어떤 데이터가 가장 중요한지 스스로 선택할 수 있었습니다. 스트리밍 프로그램은 더 신선한 프레임을 고르거나, 화질을 낮추거나, 그랜트에 맞춰 정보를 재패킷화할 수 있었습니다. 오래된 프레임이 굳이 일반 운영체제 큐에서 먼저 제출됐다는 이유만으로 대기할 필요는 없었습니다.

바로 이 늦은 선택 덕분에 분리가 유용했습니다. 혼잡 제어는 공유되면서도 애플리케이션 의미론은 애플리케이션에 남았습니다. 스케줄러는 용량이 희소하다는 사실을 알고, 애플리케이션은 오래된 패킷과 키프레임, 작은 대체물 중 무엇이 가치 있는지 알았습니다. 어느 쪽도 서로를 흉내 낼 필요가 없었습니다.

이 때문에 콜백이 수신 확인이 아니었음도 설명됩니다. CM은 자신의 제어 모델 안에서 자리를 만들었을 뿐입니다. 그 시점에 패킷이 실제로 만들어졌거나, IP로 넘겨졌거나, 인터페이스에서 접수되었을 보장은 없습니다. 콜백을 전송 증거로 취급하면 적응을 가능하게 한 그 의도적 간극이 사라집니다.

권한은 만료되었고, 쓰이지 않은 권한은 반환되었다

전송 기회는 시간적으로 한정되었습니다. RFC 3124는 왕복 시간(RTT)과 구현 정의 임계값 중 큰 값이 지난 후 만료된다고 규정했습니다. 만료된 콜백을 받은 애플리케이션은 그것을 사용할 권리가 없었습니다. 혼잡 상태는 시간에 따라 변하며, 오래된 창에서 파생된 그랜트는 지속적인 크레딧으로 보존될 수 없습니다.

콜백을 사용한 뒤 애플리케이션은 IP 출력 경로에서 실제로 제출한 바이트 수를cm_notify로 보고했습니다. 전송하지 못했다면 0을 보고해야 했습니다. 이 0은 사용되지 않은 기회를 돌려 다른 요청이 진행될 수 있게 했습니다. 그래서 프로토콜에는 작지만 중요한 회계 루프가 있었습니다: 요청, 그랜트, 실제 사용 통지.

RFC 3124는 루프가 끊어졌을 때의 견고성도 요구했습니다. 애플리케이션이 충돌하거나 0 통지를 반환하지 못할 수 있습니다. CM은 완벽한 동작을 영원히 기다리며 멈출 수 없습니다. 구현은 누락된 보고에서 회복하되, 콜백을 곧바로 전송과 동일시하지 않는 방식이 필요했습니다.

nsent값은 피어가 받은 바이트가 아니라 호스트가 보낸 바이트를 의미했습니다. 이 값은 송신 측의 미확인 데이터 회계를 갱신합니다. 전달 증거는 별도 인터페이스인cm_update를 통해 도착했으며, 이는 성공적인 수신, 혼잡 통지, 손실, 피드백 부재 같은 보고들을 구분했습니다. 이 구분 덕분에 세 시점—허가, 로컬 송출, 원격 증거—을 각각 관찰할 수 있었습니다.

매크로플로우는 통제 가설이었다

혼잡 행동을 공유하는 흐름들은 하나의 매크로플로우에 넣을 수 있었습니다. 그러면 공통의 혼잡 제어 및 스케줄링 상태를 사용하게 됩니다. 애플리케이션이 그룹화에 영향을 줄 수도 있었는데, 어떤 흐름들이 같은 경로나 같은 관리 목적을 공유할지 가끔 알고 있었기 때문입니다.

그러나 그룹 소속이 패킷이 같은 병목을 지나간다는 증명은 아니었습니다. 라우팅은 바뀔 수 있고, 여러 인터페이스가 존재할 수 있으며, 호스트의 그룹화 규칙이 지나치게 넓을 수 있습니다. RFC 3124가 제시한 것은 통제 정보 공유 메커니즘이지 경로 정체성에 대한 암호학적 진술이 아니었습니다. 따라서 매크로플로우를 평가하는 운영자는 그룹화 키, 경로 관찰, 인터페이스 선택, 각 결정 시각을 보존해야 했습니다.

이전의 RFC 2140과 이후의 RFC 9040은 이 아이디어를 역사적으로 위치짓는 데 도움이 됩니다. 둘 다 연결 간 전송 지식의 재사용을 다루지만, RFC 3124의 고유한 기여는 애플리케이션 대면 요청/그랜트/통지 프로토콜과 공유 스케줄러였습니다. TCP의 제어 블록에 페이로드를 넣도록 강제하지 않고도 비TCP 애플리케이션이 참여할 수 있게 했습니다. 그래서 이 장은 캐시된 TCP 지표의 역사와는 다릅니다.

"모범적"은 안전장치가 아니라 계약이었다

RFC 3124는 CM 동의 하에서만 전송하고 모든 전송 데이터를 정확히 보고하는 애플리케이션을 모범적(well behaved)이라 불렀습니다. 이 표현은 인터페이스 준수를 설명한 것이지, 혼잡 관리자가 호스트의 모든 프로세스의 전송을 막을 수 있다는 뜻이 아니었습니다.

문서는 CM이 모든 애플리케이션에 혼잡 행동을 강제하지 않으며, 침해된 호스트로부터 네트워크를 보호하지도 않는다고 명시했습니다. 비참여 프로그램이나 악성 프로그램은 인터페이스를 우회할 수 있었습니다. 호스트 단위 감시나 라우터 강제는 명세 밖의 별도 기계 장치였습니다.

이 경계는 흔한 역사적 과잉 주장을 막습니다. CM 구현을 실행하는 호스트가 그것만으로 혼잡에 안전해지지는 않습니다. 모듈 존재의 증거는, 특정 애플리케이션이 그것을 사용했다는 증거, 호출이 전송과 일치했다는 증거, 경쟁 트래픽이 우회하지 않았다는 증거, 해당 패킷이 측정된 경로를 따랐다는 증거와 결합되어야 합니다.

선택적 채택도 중요했습니다. 애플리케이션은 CM 사용을 강제받지 않았습니다. 사용한다면 RFC가 그 행동 방식을 정의했습니다. 표준 지위는 프로토콜 계약을 확립했지, 배포·강제·시장 수용을 확립하지 않았습니다.

조회는 용량을 날조하지 않고 불확실성을 노출할 수 있었다

동기 인터페이스는 CM 추정치를 원하되 자체 전송 루프를 유지하는 애플리케이션을 위해 마련되었습니다.cm_query를 통해 애플리케이션은 속도, 왕복 시간, 혼잡 정보를 얻을 수 있었습니다. 유효하지 않은 추정치는 음수 값으로 표현되었습니다. 결과가 숫자처럼 보이도록 0으로 대체되지는 않았습니다.

이 선택은 불확실성을 데이터로 보존했습니다. 알 수 없는 추정치와 측정된 용량 0은 다릅니다. 둘을 혼동하면 애플리케이션이 불필요하게 멈추거나, 측정 부재를 안정적 한도로 여길 수 있습니다. 같은 원칙이 역사적 증거에도 적용됩니다: 배포 확인증의 부재를 실패로 바꿀 수 없고, 표준 문서를 채택으로 바꿀 수 없습니다.

RFC 2914의 혼잡 제어 원칙, RFC 2581의 TCP 동작, RFC 2861의 유휴 혼잡 윈도 처리, RFC 2481의 실험적 ECN 연구가 주변 기술 어휘를 제공했습니다. RFC 1191이 경로 MTU 맥락을 제공했고, RFC 5681과 RFC 8085는 이후 전송 및 UDP 책임을 재정립했습니다. 이 문서들은 CM이 다룬 문제를 밝혀주지만, 어느 것도 특정 운영체제나 애플리케이션이 RFC 3124를 사용했다는 증명은 아닙니다.

증거 사슬은 콜백 하나보다 길었다

방어 가능한 운영 기록은 애플리케이션 요청과 매크로플로우 정체성에서 시작됩니다. 스케줄러 상태, 그랜트 크기와 타임스탬프, 만료 계산, 애플리케이션이 선택한 페이로드, IP 출력 시점의cm_notify수치, 경로와 인터페이스 증거, 그 이후의cm_update피드백을 보존해야 합니다. 전달이나 사용자 체감 품질에는 더 많은 관찰이 필요합니다.

각 항목은 서로 다른 질문에 답합니다. 요청은 수요가 선언되었음을 증명합니다. 콜백은 스케줄러가 유한한 기회를 제시했음을 증명합니다. 양수 통지는 애플리케이션이 송신 측 IP 경로에서 바이트를 보고했음을 증명합니다. 수신자 피드백은 도착이나 혼잡에 대한 주장을 뒷받침할 수 있습니다. 어느 것도 다른 것들을 조용히 대신할 수 없습니다.

그래서 RFC 3124를 가장 잘 설명하는 표현은 "전송 그랜트"입니다. 이미 큐에 들어간 패킷의 거짓 구체성도, 성공한 전송의 거짓 최종성도 피할 수 있습니다. 관리자는 시점과 공유 혼잡 상태를 다스렸고, 애플리케이션은 콘텐츠 선택을 유지했으며, 호스트 네트워크 스택이 송출을 수행하고, 경로와 수신자가 결과를 만들어냈습니다.

RFC가 남긴 오래된 교훈은 하나의 관리자가 기계 전체를 명령할 수 있다는 것이 아니었습니다. 공유된 통제 표면은 권한, 사용, 결과가 각각 별도로 관찰 가능할 때에만 신뢰할 수 있다는 것이었습니다.

출처

  1. https://www.rfc-editor.org/rfc/rfc3124.txt
  2. https://www.rfc-editor.org/info/rfc3124
  3. https://datatracker.ietf.org/doc/rfc3124/
  4. https://www.rfc-editor.org/rfc/rfc2140.txt
  5. https://www.rfc-editor.org/rfc/rfc2914.txt
  6. https://www.rfc-editor.org/rfc/rfc2581.txt
  7. https://www.rfc-editor.org/rfc/rfc2861.txt
  8. https://www.rfc-editor.org/rfc/rfc2481.txt
  9. https://www.rfc-editor.org/rfc/rfc1191.txt
  10. https://www.rfc-editor.org/rfc/rfc5681.txt
  11. https://www.rfc-editor.org/rfc/rfc8085.txt
  12. https://www.rfc-editor.org/rfc/rfc9040.txt