Summary

  • STAMP CoS ECN 초안 02판은 응답 패킷에 적용할 ECN 값을 요청하는 EC1, 반사기가 그 값을 적용했는지 알리는 RPE를 더한다. 기존 EC2는 반사기에 도착한 시험 패킷의 ECN 값을 전한다.
  • 요청 값을 설정했다면 RPE=0b11, 실패해 영값을 썼다면 0b10이다. RFC 8972만 아는 옛 반사기는 새 비트를 예약 영역으로 취급해 0b00을 돌려주므로 새 귀로 검사를 수행했다고 볼 수 없다.
  • 한 RTT 안에 ECT 표식이 있는 탐침을 여러 개 보내는 송신자는 CE 혼잡 표식을 관찰하고 자신이 내보내거나 유발한 트래픽을 줄일 수 있어야 한다.

RFC 8762의 STAMP는 송신자가 시험 패킷을 보내고 반사기가 답하는 구조다. 절차가 단순해 측정을 반복하기 쉽다. 하지만 반복 횟수를 높이면 탐침도 다른 패킷과 함께 큐에 줄을 선다. 반사기의 응답도 돌아오는 경로에서 용량을 사용한다. 혼잡 감지 시스템은 창밖에서 교통량을 세는 사람이 아니라 도로 위의 차량 한 대다.

RFC 8972는 반사기에 도착한 패킷의 ECN 값을 EC2에 복사해 돌려주는 서비스 등급 확장을 정의했다. 송신자는 가는 길에서 패킷에 어떤 표식이 붙었는지 볼 수 있었다. 돌아오는 길은 달랐다. 반사기가 응답의 IP 헤더에 특정 ECN 값을 넣었는지 요구하고 확인하는 방법이 부족했다. 표식이 없는 응답을 받았다는 사실만으로 ECN 지원 패킷이 귀로에서 어떻게 처리됐는지 알 수 없었다.

2026년 11월 2일 개정 초안은 옛 예약 비트를 활용한다. 송신자가 EC1에 원하는 귀로 값을 넣고, 반사기는 도착 시 값은 EC2에 적는다. 요청한 귀로 값을 적용할 수 있으면 RPE=0b11; 로컬 정책이나 장비 제약 때문에 적용할 수 없으면 IP 헤더를 0b00으로 설정하고 RPE=0b10을 반환한다. 송신자는 실제 돌아온 헤더도 확인한다. 상대가 무엇을 받았는지, 무엇을 보내려 했는지, 자신이 무엇을 받았는지 따로 남기는 방식이다.

이 구분은 구형 장비를 만났을 때 중요하다. RFC 8972까지만 구현한 반사기는 새 필드를 예약 비트로 무시하고 RPE=0b00을 돌려준다. 송신자는 귀로 ECN 측정 기능이 없다는 것을 알 수 있다. 0b10이면 기능은 알지만 요청한 표식을 넣지 못했다는 뜻이다. 두 경우 모두 CE가 없었다는 결과를 곧장 귀로의 무혼잡 증명으로 내세우면 측정 조건부터 틀린다.

초안은 결과를 읽은 뒤의 행동도 적었다. ECT(0) 또는 ECT(1) 시험 패킷을 한 RTT 안에 여러 개 보내면 송신자는 돌아온 EC2의 CE를 살피고 송신 속도를 낮출 능력이 있어야 한다. EC1로 ECT 응답을 요구했다면 돌아온 IP 헤더의 CE를 보고 자신이 유발한 응답 부하를 줄일 수 있어야 한다. 한 시험으로 여러 응답을 만들도록 요청하는 제어 확장을 쓰는 경우에는 이후 요청의 응답 조건도 조정해야 한다.

감속 알고리즘 자체는 구현이 정하지만 RFC 3168과 RFC 9330의 혼잡 응답 조건을 따른다. 과부하 상태에서 CE가 어떻게 붙는지 알아보려고 일정 속도를 유지하는 실험은 테스트하는 망 운영자의 동의를 받은 통제 환경에서만 허용되며, 속도·기간·주변 트래픽에 미칠 영향을 제한해야 한다. 평상시 감시는 이 실험의 이름을 빌릴 수 없다.

관찰값과 관찰자의 행동

출발 시 ECN과 EC2, 요청한 EC1과 RPE, 귀환 헤더를 맞춰 보면 어느 구간에서 표식이 달라졌는지 단서를 얻는다. 양 끝의 기록만으로 바꾼 중간 장비를 특정할 수는 없다. CE 없는 응답 하나가 전체 경로의 모든 트래픽을 대표하지도 않는다. 실제 도입을 주장하려면 왕복 패킷의 시간 기록, 필드 값, 탐침 빈도, 응답 수, CE 뒤 송신자가 실행한 감속을 함께 보여야 한다.

이 문서는 아직 IETF 작업반의 진행 중인 초안이다. 그러나 운영상 질문은 명확하다. 측정 시스템이 혼잡을 찾아냈을 때, 자신의 패킷은 얼마나 줄였는가? 관찰 보고서에서 그 답이 빠지면 탐침도 혼잡의 익명 참가자로 남는다.

초안 02판 · RFC 8972 · RFC 8762