요약

  • RFC 3006는 발신자의 원래 트래픽 명세를 그대로 유지하되, 각 라우터가 자신의 링크가 명시된 압축을 지원하는 경우에만 사용할 수 있는 압축 가능성 힌트를 추가했다.
  • 할인된 압축 레이트로 플로우를 허용한 라우터는 마치 네트워크 에지처럼 그 더 작은 예산을 폴리싱해야 했으며, 부정확한 주장의 하락 리스크는 그 혜택을 받은 플로우에 귀속되었다.

어떤 라우터가 엔드 호스트는 안전하게 숫자에 담을 수 없는 정보를 알고 있다면, 예약은 실제보다 크게 보였다.RFC 3006의 실제 예제에서 발신자는 120바이트 패킷으로 구성된 48 kbit/s 스트림을 기술했다. 제약된 인터페이스는 IP, UDP, RTP 헤더 40바이트를 4바이트로 압축할 수 있었다. 그 홉에서 패킷은 압축되지 않은 크기의 70퍼센트를 차지하게 되므로, 라우터는 48이 아닌 33.6 kbit/s를 예산으로 잡을 수 있었다.

이 계산은 사소한 최적화처럼 보인다. 그러나 실제로는 지식의 분업을 드러냈다. 발신자는 자신이 내보낼 트래픽의 종류를 알았다. 라우터는 특정 출력 인터페이스가 해당 압축기를 구동하는지 알았다. 어느 쪽도 모든 홉에 대해 엔드투엔드 수요를 다시 쓸 만큼 충분히 알지 못했다. 어떤 링크는 압축할 수 있고 다른 링크는 그렇지 않을 수 있다. 단순히 33.6 kbit/s를 광고한 발신자는 경로에서 압축되지 않는 구간에서 자신의 비용을 과소 보고하게 된다. 48 kbit/s만 본 라우터는 자신의 링크가 감당할 수 있는 예약을 거부할 수도 있다.

RFC 3006는 어느 쪽도 전역적 권위를 갖지 않는다는 전제 하에 이 불일치를 해소했다. 전송되는 Sender TSpec은RFC 2210에서 정의한 RSVP 용법과 일치하도록 변경되지 않았다. 새로운 힌트는 가능한 압축 방식과 선택적 백분율 인자를 기술했다. 네트워크 요소는 그 정보를 로컬에서 도출한 압축된 TSpec에 대한 입력 하나로 취급할 수 있었다. “힌트(hint)”라는 단어는 정확했다. 그것은 명령도 아니었고, 광고된 절감이 실제로 실현될 것이라는 증거도 아니었다.

이 구분은 RSVP 자체의 역할 분담을 따랐다.RFC 2205는 엔드포인트와 네트워크 요소 사이에 정보를 전달했고, 어드미션 컨트롤과 트래픽 컨트롤이 자원의 존재 여부를 결정했다. RFC 3006는 힌트를 Sender TSpec에 배치했다. 발신자가 스트림의 예상 구조를 알고 있었고, RSVP 메시지 처리가 아니라 트래픽 컨트롤이 그 정보를 필요로 했기 때문이다. 공용 객체는 주장을 실었고, 홉에서 실행되는 코드가 그 주장이 유용한지 판단했다.

예제는 이어서 로컬 계산을 구체화했다. 원래 토큰 버킷 레이트r는 48 kbit/s, 깊이b는 120바이트, 최대 패킷 크기M은 120바이트, 최소 폴리싱 단위m은 64바이트였다. 70퍼센트 인자는r를 33.6 kbit/s로,b와M을 84바이트로 줄였다. 최소 단위에는 다른 계산이 필요했다. 64에서 동일한 36바이트의 헤더를 빼 28바이트를 만드는 것이었다. 이 공식은 “모든 필드에 0.7을 곱하고 희망하기”가 아니었다.

고정N바이트를 제거하는 헤더 압축기의 경우, RFC 3006는 레이트와 버스트 깊이를f/100으로 조정하고, 피크 레이트는 그대로 두며, 최대·최소 패킷 크기에서N을 뺐다. 그리고 고정 절감 모델이 모든 압축 알고리즘을 설명하지는 않는다고 경고했다. UDP 체크섬의 존재 여부, RTP 타임스탬프의 선형성, 패킷 크기 분포가 결과를 바꿀 수 있었다. 라우터는 발신자의 백분율을 수용하는 대신 보수적인 계산을 선택할 수 있었다. 인자 0은 계산을 라우터에 명시적으로 맡긴다는 뜻이었고, 100은 절감을 기대하지 않는다는 뜻이었다.

이 메커니즘은 수많은 발신자를 다뤄야 했다. 각 발신자의 TSpec은 해당 발신자 자신의 인자로 먼저 축소된 뒤에 적용 가능한 발신자 명세들이 결합되었다.RFC 2212의 보장형 서비스에서는 수신자의 레이트를 이 인자들의 버스트 크기 가중 평균으로 조정할 수 있었다. 그러나R만 줄이면 지연에 대한C/R기여가 커지므로, 해당 홉은 자신의C오차항을 역비율로 늘려야 했다. 약속된 지연 의미 체계가 그대로 유지될 때만 대역폭 할인이 유효했다.

가장 중요한 단락은 낙관적인 산수가 끝나는 지점에서 시작했다. 압축은 완전히 결정론적이지 않다. 라우터가 33.6을 소비할 것이라 가정하고 48 kbit/s 플로우를 허용했는데 실제 압축기가 35를 내주었다고 하자. 초과된 1.4 kbit/s는 예약되지 않은 상태였다. 그것은 선택된 통합 서비스(Integrated Services) 클래스의 규칙에 따라 처리되는 초과 트래픽이 되었다. 용량 할인은 추정을 권리로 바꾸지 않았다.

허위 진술도 전략적으로 발생할 수 있었다. 발신자는 압축되지 않는 데이터를 압축 가능하다고 표시하거나 절감을 과장할 수 있었다. 그렇게 되면 거부되어야 할 플로우가 허용되고, 정직하게 예약한 플로우들에는 자원이 부족해진다. RFC 3006는 할인을 만든 주장에 그 결과를 귀속시켰다. 힌트를 사용한 라우터는 자신이 네트워크 에지인 것처럼 그 스트림을 압축된 TSpec 기준으로 폴리싱해야 한다.

이것은 책임의 미묘한 이동이었다. RSVP는 모든 홉에서의 폴리싱을 요구하지 않았다. 그러나 압축을 인식하는 홉은 실제 네트워크 에지가 볼 수 없는 새로운 로컬 경계를 만들어냈다. 압축되지 않은 TSpec 기준의 상류 폴리싱은 발신자가 48 kbit/s 안에 머물렀음을 증명할 수는 있었지만, 하류 링크가 할인된 33.6 이하만 받았다는 것은 증명할 수 없었다. 따라서 절감을 소비한 라우터가 그 절감의 검증 지점이 되었다.

최대 데이터그램 크기는 또 하나의 비대칭을 보존했다. 폴리싱에M을 사용하는 서비스는 압축되지 않은 값을 유지해야 했다. 일부 패킷은 압축에 실패할 수 있기 때문이다. 예약 모델은 모든 개별 패킷이 항상 줄어든다고 가장하지 않으면서도 반복되는 회선 비용은 할인할 수 있었다. 평균 효율과 최악의 경우 허용 가능성은 서로 다른 영수증이었다.

하위 호환성이 이 제어 루프를 완성했다. 힌트를 이해하지 못하는 구형 라우터는 이상적으로 그것을 로컬에서 무시하고, 변경 없이 전달하고, 원래 TSpec 기준으로 예약해야 했다. 경로 뒤에 위치한 유능한 라우터는 여전히 그것을 사용할 수 있었다. 그러나RFC 2210은 알려지지 않은 파라미터 처리를 완전히 명시하지 않았기 때문에 일부 구현은 PATH 메시지를 거부할 수 있었다. RFC 3006는 PathErr 응답과 힌트 없이의 재시도를 허용했다. 이 확장은 조용히 할인을 발명하는 대신, 더 비싸지만 이해 가능한 계약으로 폴백할 수 있었다.

주변의 저속 관련 작업은 이 글이 다루지 않는 영역을 보여준다.RFC 2688은 프레이밍, 단편화, 스터핑, 링크 레이트 변경 후의 유효 PPP 회선 비용을 계산했다.RFC 2689는 희소한 링크에서 프레이밍, 압축, 명시적 애플리케이션 지식이 협력해야 하는 이유를 설명했다. RFC 3006는 주장과 집행 사이의 더 좁은 교환, 즉 누가 압축 가능성을 기술할 수 있고, 누가 그것을 로컬 용량으로 변환할 수 있으며, 변환이 기대에 못 미칠 때 누가 하락 리스크를 부담하는지를 다루었다.

이후RFC 3241은 PPP 상의 ROHC를 위해 일련의 RSVP 힌트 값을 할당하고 RFC 3006을 규범적으로 재사용했다. 이는 힌트 형식이 다른 압축 프레임워크로 확장될 수 있음을 증명한다. 그러나 광범위한 배포, 시장 성공, 현대 QoS로의 직접적 인과 경로를 증명하지는 않는다. 이 역사적 가치는 표준 자체에 드러난 의사결정 구조에 있다.

Lu Heng의 Running-Code Primacy 관점에서 읽으면, 라우터의 권위는 시그널링 객체에 담긴 숫자를 보유했기 때문이 아니라 실행 가능한 능력에서 나왔다. 최소 공통 계층은 로컬 결정에 필요한 충분한 정보를 실었지만, 모든 홉에 하나의 미래를 강제하지 않았다. 안정성 문제도 마찬가지로 구체적이었다. 예약이 운영적으로 안정적인 것은 관측된 압축이 어드미션이 의존한 할인을 계속 지지할 때만이었다.

요컨대 RFC 3006는 자원 약속을 유한한 영수증의 사슬로 다루었다. 발신자가 기술하고, 홉이 능력을 검증하고, 어드미션이 계산하고, 트래픽 컨트롤이 폴리싱하고, 호환성이 선택적 주장이 경로를 통과했는지를 결정한다. 그 영수증들 중 어느 하나만으로는 서비스 결과가 증명되지 않는다. 함께 작동할 때, 이들은 로컬 효율 이득을 다른 모두에게 보이지 않는 리스크로 전환하지 않고 사용 가능하게 만들었다.

출처