요약

  • RFC 3387은 QoS 메커니즘 위에 빠져 있던 계층을 발견했다. 누구도 일관된 서비스를 정의·인가·검증·과금하기 전에 패킷이 차등적인 처리를 받을 수 있었다.
  • 이 문서의 지속적인 기여는 접속 지점, 코어, 도메인 경계에 걸친 영수증 지도였고, 프리미엄 용량과 중앙화된 관리가 그것이 개선하려던 최선노력 시스템을 손상할 수 있다는 경고였다.

가장 깔끔한 시연 장면을 상상해 보라. 패킷이 클래스 표시를 달고 도착한다. 분류기가 이를 인식한다. 스케줄러가 일반 트래픽보다 먼저 통과시켜 준다. 라우터는 실제로 관찰 가능한 무언가를 해냈다.

이제 어떤 서비스가 전달되었는지 물어보라.

누가 그 처리를 받을 자격이 있었는가? 어떤 수량적 약속이 적용되었는가? 경로가 충분한 자원을 할당받았는가? 같은 해석이 다음 사업자 경계에서도 살아남았는가? 적합성을 누가 측정하고, 누가 그 측정에 이의를 제기할 수 있으며, 반환 경로가 다른 주체에 속한다면 무엇이 과금될 것인가? 큐에는 답이 없다. 큐의 성공은 사슬 속 영수증 하나일 뿐이고, 그 사슬의 다른 고리는 아직 존재하지 않을 수 있다.

바로 이 간극이 2002년 9월 IRTF Service Management Research Group 멤버들이 발표한 RFC 3387의 주제였다. 이 메모는 Informational 등급이었다. 어떤 프로토콜도 표준화하지 않았고 완료된 배포도 보고하지 않았다. 그 가치는 차등 포워딩에 대한 작업이, 포워딩 동작을 정직한 서비스로 바꾸는 데 필요한 기제를 앞질러 달리고 있다는 사실을 포착한 데 있었다.

초기 IP 관리는 단순성을 중시하고 중앙 집중적 통제를 피했다. 최선노력(best effort)은 그 아키텍처에 맞았다. 네트워크는 할 수 있는 만큼 전달하고, 애플리케이션이 적응하며, 관리는 주로 장치와 통계에 집중되었다. QoS는 관리 대상 자체를 바꾸었다. 한 플로우가 다른 플로우와 다른 처리를 받을 수 있게 되자, 운영자는 그 차이가 무엇을 의미하는지, 누가 요청할 수 있는지, 그리고 조각난 네트워크를 넘어 어떻게 증명될 것인지를 설명해야 했다.

RFC 3387은 서비스 정의와 서비스 실현을 분리했다. 정의는 상품을 모호하지 않게 묘사해야 했다. 실현은 그 정의를 실제 네트워크 역량에 매핑해야 했다. 정책 객체나 서비스 이름은 의도를 표현할 수 있었지만, 의도는 자원 허가가 아니었다. 구성된 메커니즘은 설계의 일부를 실체화할 수 있었지만, 구성은 측정된 전달이 아니었다.

이 메모는 빠져 있던 작업을 세 개의 표면에 배치했다. 접속 지점에서는 자원 허가 제어, 인증, 인가, 과금 지원, 트래픽이 합의된 매개변수 내에 머무는지의 검증이 필요했다. 또한 서비스 검증, 장애 통지, 재실체화, 종료를 위한 인터페이스도 필요했다.

코어 내부에서는 작업의 성격이 달라졌다. 트래픽 엔지니어링에는 가용 자원과 혼잡에 대한 시야가 필요했다. 장치는 용량을 보고하고, 포워딩 지시를 받고, 장애를 탐지하고, 복구해야 했다. RFC 3387은 더 중앙화된 계산도 탐색했는데, 일부 결정은 단일 포워딩 홉이 가지지 못한 네트워크 전역 정보에 의존했기 때문이다. 그러면서도 더 어려운 아키텍처 질문을 반복했다. 서비스 기능을 네트워크에 두는 이점이 그 복잡성과 불안정화 위험을 능가하는가?

행정 경계에서는 영수증 사슬이 기술적일 뿐 아니라 정치적이 되었다. 경쟁하는 사업자들은 서비스 시그널링, 계정 관리, 검증, 트래픽 측정, 과금 정보 교환을 필요로 하면서도 민감한 내부 용량 공개는 거부할 수 있었다. 쌍방향 SLA는 하나의 경계 합의를 표현했고, 긴 경로는 그런 합의를 여럿 필요로 할 수 있었다. 그 합의들을 이어 붙인다고 해서 자동으로 하나의 수량적 종단간 약속이 만들어지지는 않았다.

이 메모는 대역폭 브로커와 신뢰할 수 있는 제3자를 가능한 구성 요소로 검토했다. 그러나 그들을 주권적이거나 필수적인 것으로 만들지는 않았다. 그 매력은 기능적이었다. 누군가 모든 운영자의 내부 네트워크를 노출하지 않고 허가, 가격, 지불 또는 검증을 조율할 수 있었다. 그 위험은 역시 구조적이었다. 협력을 단순화하려고 도입된 구성 요소가 피어 도메인들을 지배하는 중앙 통제 지점이 될 수 있었다.

과금은 이 구분을 무시할 수 없게 만들었다. RFC 3387은 과금이 보안과 함께 서비스 설계 시점에 설계되어야 한다고 밝혔다. 모든 서비스마다 맞춤형 과금·보안 시스템을 새로 만드는 것은 실용적이지 않았고, 패킷을 운반하는 제공자가 두 기능을 모두 맡으리라 가정하는 것도 안전하지 않았다.

RFC 2975는 기록들을 구분하는 데 도움을 준다. 계정 관리(accounting)는 자원 소비에 대한 정보를 수집한다. 요금 부과(charging)는 요율이나 가격 논리를 적용한다. 청구(billing)는 요금을 지불 요구로 바꾼다. 지불(payment)은 그 요구를 정산한다. 이들은 관련된 데이터를 사용할 수 있지만 하나의 사건이 아니다. 카운터는 정확하면서 요율이 틀릴 수 있고, 청구서는 올바르면서 미납일 수 있으며, 지불이 이루어졌는데도 약속된 경로는 실패했을 수 있다.

같은 규율이 패킷 처리에도 적용된다. DiffServ는 홉 단위 동작(per-hop behavior)과 경계 조건화를 정의했다. RFC 3387은 홉 단위 클래스 보장이 종단간 보장이 아니라고 직접 말했다. 프리미엄을 지불하는 고객은 경로 전체의 대역폭, 지연, 오류 한계를 신경 쓴다. 한 도메인의 성공적인 스케줄링 결정은 다른 모든 도메인을 증언할 수 없었다.

따라서 접속 지점/코어/경계 지도는 제한된 영수증들의 사슬이 된다. 자격 증명은 명시된 규칙 아래에서 주체를 식별한다. 인가는 요청을 허용한다. 허가(admission)는 모델링된 자원을 확약한다. 분류기는 패킷을 배정한다. 미터는 선정된 트래픽을 관찰한다. 스케줄러는 국소 처리를 적용한다. 경계 기록은 인계를 묘사한다. 서비스 검증은 관찰을 계약과 비교한다. 계정 관리는 과금 대상 사용을 기록한다. 청구는 재정적 청구권을 만든다. 애플리케이션은 작업이 실제로 성공했는지 관찰한다.

그 어떤 영수증도, 시스템에 더 나은 측정이 없다는 이유만으로 다음 영수증으로 격상되어서는 안 된다.

위험은 프리미엄 서비스를 구매하지 않은 트래픽에까지 미쳤다. 예약된 용량은 놀고 있으면서도 최선노력에 이용 불가능할 수 있다. 높은 우선순위의 플로우들은 일반 트래픽이 평소에 사용했을 자원을 소모할 수 있다. RFC 3387은 수익 창출 서비스가 덜 수익성 있는 최선노력 인터넷의 희생을 대가로 올 수 있다고 경고했다. 그러나 그 피해에 대한 측정을 제시하지는 않았고, 어떤 아키텍처든 드러내야 할 유인을 확인했을 뿐이다.

바로 여기서 Lu Heng의 Running-Code Primacy가 이 역사를 선명하게 만든다. 공통 계층은 상호운용성과 검증 가능한 안전이 요구하는 것만을 명시해야 한다. 사업자는 경계에서 인가된 서비스를 인식하고, 합의된 매개변수를 측정하고, 책임을 정산하기에 충분한 공유 의미 체계를 필요로 한다. 그렇다고 해서 하나의 중앙 기관이 모든 독립 네트워크가 서비스를 공급하거나 가격을 매기는 방식을 통제해야 하는 것은 아니다.

Minimum Initial Specification은 건설적인 규칙을 준다. 경계 계약을 좁고 결정론적으로 정의하라. 내부 용량 선택은 국지적으로 유지하라. 미래의 메커니즘은 자발적 운영 채택으로 승리하게 하라. 공통 영수증 형식은 기록자, 검증자 또는 브로커를 유효성의 원천으로 만들지 않고도 협력을 지원할 수 있다.

RFC 3387은 이 아키텍처를 완성하지 못했다. 프로토콜보다 질문을 더 많이 남겼다. 그 불완전성이야말로 역사적 요점이다. 2002년 무렵, 인터넷이 그 특권을 둘러싼 서비스 전체를 설명할 수 있기 전에도 패킷에 특권을 보이게 만드는 것은 가능했다.

큐는 패킷을 구별할 수 있었다. 그러나 운영자는 여전히 서비스를 정의하고, 허가하고, 증명하고, 계정 처리하고, 경계를 넘어 정산하고, 다른 모든 이의 최선노력이 조용히 비용을 치르지 않았음을 보여줘야 했다.

출처