요약

  • RFC 1272는 엔드포인트 IP 주소만으로는 사업자가 어느 직접 인접 관리 도메인이 트래픽을 자기 경계 너머로 운반했는지 판별할 수 없다고 주장했다.
  • 경계 계량기는 정산을 지원할 수 있었지만, 유용한 세부 정보는 토폴로지, 선택한 세분화 수준, 저장 용량, 수집 비용과 보안에 달려 있었다.
  • 이 메모는 사용량 보고를 과금과 정책 집행에서 분리했고, 라우터 수신 시점과 송출 시점 중 어느 쪽에서 패킷을 셀지에 대한 논쟁은 해결하지 않은 채로 남겨두었다.

빠져 있던 이름은 이웃이었다

IP 패킷에는 출발지 주소와 목적지 주소가 있다. 덕분에 엔드포인트 간 트래픽을 셀 수는 있지만, 그것만으로는 어느 이웃 네트워크가 그 패킷을 사업자의 도메인 안으로 전달했는지 알 수 없다. 한 엔드 시스템에서 오는 트래픽이 서로 다른 인접 도메인을 통해 도착할 수 있다면, 엔드포인트를 완전히 기록했더라도 사업자의 더 좁은 질문에는 답할 수 없다. 이 트래픽은 내 경계에서 누구의 네트워크를 통과했는가?

RFC 1272의 답은 인터넷의 모든 사용자에 대해 모든 네트워크가 정산하도록 만드는 것이 아니었다. 그 모델은 각 관리 주체를 자신의 도메인과 직접 연결된 인접 도메인에 집중시켰다. 한 사업자는 이웃과의 경계를 넘는 트래픽을 측정하고 그 이웃과 정산 명세를 교환할 수 있다. 이웃이 자신의 비용을 더 하류에서 배분해야 한다면, 그것은 이웃의 책임이 된다. 설계는 재귀적이었다. 각 관리 주체는 관찰 가능한 관계만 정산하며, 최종 사용자에 대한 전 지구적 시각을 갖고 있다는 가정을 하지 않는다.

이 구분은 계량기의 위치가 어디서 의미를 갖는지 바꾼다. 호스트는 엔드포인트에서 트래픽을 관찰할 수 있다. 네트워크 경계에 있는 라우터는 로컬 도메인에 들어오거나 나가는 트래픽을 보며 인접 상호접속에 대한 근거를 제공할 수 있다. 이 메모는 IP 헤더만으로는 이 중간 시스템의 식별 정보를 얻을 수 없으며, 경계 구성 요소에 대한 하위 계층 정보나 설정이 필요할 수 있다고 밝혔다. 패킷의 엔드포인트 필드와 사업자의 정산 경계는 서로 다른 질문에 답한다.

측정에도 그 자체의 비용이 있었다

계량기의 위치는 설계 선택 중 하나일 뿐이었다. RFC 1272는 전용 네트워크 모니터, 라인 모니터, 라우터 내부의 소프트웨어 계량기, 그리고 협조적인 “router spider”를 언급했다. 가장 편리한 위치는 토폴로지와 측정하려는 서비스에 따라 달라진다. 경계 배치는 사업자와 고객이 서로의 기록을 비교하는 데 도움이 될 수 있지만, 모든 라우터에 계량기를 장착하라는 만능 명령은 아니었다.

이 메모는 세부 수준을 경제적·기술적 판단으로 다루었다. 계량기는 포트, 네트워크 또는 호스트 단위로 셀 수 있고, 패킷 속성을 추가할 수 있으며, 카운터나 타임스탬프를 보존하고, 서로 다른 간격으로 보고할 수 있다. 추가되는 엔터티/속성 조합마다 또 하나의 플로우 레코드가 필요할 수 있다. 더 세분화된 레코드는 메모리와 처리량을 소모하고, 더 자주 이루어지는 보고는 대역폭과 수집기 용량을 소모한다. 완전한 정확성과 신뢰성이 요구된다면 모든 패킷을 검사해야 한다. 반면 동작 이해, 네트워크 튜닝, 비용 분담 근사 같은 목적에는 샘플링이 더 낮은 비용으로 충분할 수 있다. 이는 서로 다른 증거 기준이며, 서로 바꿔 쓸 수 있는 방법이 아니다.

수집 행위 자체도 보호되어야 했다. 저자들은 사용량 정보를 민감한 것으로 보고 기밀성, 무결성, 수집 통제를 우려 사항으로 꼽았다. 승인 및 재전송, 이중 수집기, 계량기에서의 백업 저장 등을 데이터 보존 방법으로 논의했다. 라우터에서 수집된 수치가 경계에 위치한다는 이유만으로 자동으로 신뢰할 만한 완전한 정산 기록이 되는 것은 아니다.

카운트는 청구서도 규칙도 아니었다

RFC 1272는 자신의 목적을 명확히 한정했다. 이 문서는 사용량 보고 아키텍처에 대한 배경 자료이며 인터넷 표준이 아니었다. 보고서는 가입자가 동작을 이해하도록 돕고, 사업자가 정책 준수 여부를 측정하도록 돕고, 비용 배분에 기여할 수 있다고 했다. 그러나 보고만으로는 정책을 집행할 수 없으며, 이 문서는 과금 관행을 권고하지 않았다. 재전송된 패킷의 비용을 누가 부담할지도 해결하지 않았다.

하나의 질문은 의도적으로 열어두었다. 과금 체계는 라우터가 패킷을 받을 때 셀 것인가, 아니면 라우터가 전달할 때만 셀 것인가? 라우터는 혼잡 시 패킷을 폐기할 수 있다. 수신 카운트는 제공된 트래픽이 소비한 자원을 반영하고, 송출 카운트는 전달되지 않은 트래픽에 대한 과금을 피한다. RFC 1272는 이 논쟁이 보편적 기술적 답이 아니라 정책과 맥락에 달려 있기 때문에, 아키텍처가 어느 쪽이든 선택할 수 있어야 한다고 요구했다.

이후 RFC 2722가 트래픽 플로우 측정 아키텍처를 규정했다. 그 후속 작업은 측정 체계의 역사의 일부이지, 특정 과금 모델이나 1991년 과금 비전 전체가 실제로 운영되었다는 증명이 아니다. RFC 1272가 남긴 지속적인 설계 질문은 더 소박하다. 한 관리 주체가 자기 경계에서 실제로 알 수 있는 것은 무엇이며, 어느 정도의 측정이 비용을 치를 만한가? 답은 관찰된 플로우에서, 식별된 이웃으로, 보고서로, 그리고 이후의 가격이나 집행 결정으로 이어지는 연쇄를 보존해야 한다. 그 어느 것도 패킷 양 끝의 IP 주소만으로 자동으로 도출되지 않는다.

출처:RFC 1272;RFC 2722;RFC 2990.