요약

  • IntServ는 흐름 단위의 정밀함과 수용 여부에 대한 응답을 제공했고, DiffServ는 집약적 확장성을 제공했지만 이행되지 않은 요청을 조용히 넘길 수 있었습니다.
  • RFC 2990은 두 가지 부재한 신호를 지적했습니다. 코어에서 경계로 향하는 자원 가용성 신호와, 경계에서 애플리케이션으로 향하는 성공 또는 실패 신호입니다.
  • 프리미엄 클래스가 책임 있는 약속이 되려면 탐색, 수용, 전달 서비스 측정, 사용량 회계가 하나의 폐쇄 루프를 이루어야 했습니다.

요청은 응답보다 더 먼 곳까지 갔다

품질 보장은 흔히 패킷이 더 빠른 차선에 들어서는 그림으로 그려집니다. RFC 2990은 그보다 한 단계 앞에서 출발했습니다. 유한한 네트워크에서 다른 응답을 얻으려면 하나의 동작과, 그 동작에 들어가는 부하의 양을 통제하는 규칙이 함께 필요했습니다. 수용 절차 없는 우선순위는 단지 혼잡을 옮길 뿐이었습니다. 용량 없는 약속은 희소성에 붙이는 라벨이 되어버릴 수 있었습니다.

당시 두 주요 아키텍처는 그 통제를 서로 다른 위치에 두었습니다.

통합 서비스(Integrated Services)는 애플리케이션이 흐름을 기술하고 경로를 따라 자원을 요청하도록 했습니다. 이행된 요청은 기억되는 예약 상태를 만들었습니다. 라우터는 그 흐름들에 연동된 분류기, 미터, 스케줄링 상태를 유지해야 했습니다. 이 아키텍처는 애플리케이션에게 의미 있는 거절을 줄 수 있었습니다. 노드는 자원이 존재하는 것처럼 조용히 가장하는 대신 요청을 거부할 수 있었습니다.

차등화 서비스(Differentiated Services)는 집약 쪽으로 나아갔습니다. 패킷은 홉 단위 동작을 선택하는 코드를 실었고, 경계 기능은 도메인에 들어오는 트래픽을 분류하고 조건화했습니다. 내부 라우터는 모든 애플리케이션 예약을 기억할 필요가 없었습니다. 이것이 확장성의 원천이었습니다.

그러나 이것이 다른 종류의 불확실성의 원천이기도 했습니다. 요청은 마킹되고 한쪽 경계에서 수용된 뒤, 내부 경로를 따라 서비스를 지속할 수 없음에도 집약 흐름에 실려 나아갈 수 있었습니다. RFC 2990은 그 결과를 분명히 밝혔습니다. 상태 비저장 모델에서는 네트워크가 요청을 이행할 수 없다는 사실을 애플리케이션에 알려줄 의무가 없었다는 것입니다. 애플리케이션은 관측되는 서비스로부터 실패를 스스로 추론해야 했습니다.

요청에는 전진 경로가 있었습니다. 거절에는 아직 돌아오는 경로가 정의되어 있지 않았습니다.

정밀함에는 상태 비용이 따랐다

RFC 2990은 IntServ를 단순히 옳고 DiffServ를 단순히 약하다고 기술하지 않았습니다. 그것은 트레이드오프를 구조적인 것으로 다루었습니다.

IntServ 예약은 여러 사실을 하나로 묶었습니다. 애플리케이션의 트래픽 프로파일, 하나의 경로, 그 경로에 예약된 자원, 분류 규칙, 적합성 미터가 그것입니다. 활성 요소마다 흐름을 식별하고 서비스하기에 충분한 상태를 유지해야 했습니다. 계산과 메모리 부담은 예약 수에 비례해 늘어났습니다. 세밀한 스케줄링은 가장 바쁜 라우터의 포워딩 경로에도 닿을 수 있었습니다.

그 정밀함이 비싸진 지점이 바로 캐리어 코어가 가장 많은 트래픽과 가장 많은 흐름을 처리해야 하는 곳이었습니다.

DiffServ는 많은 흐름을 소수의 집약 동작으로 압축했습니다. 코어는 애플리케이션의 전체 협상을 재현하는 대신 코드포인트에 반응하면 되었습니다. 라우터 상태가 클라이언트 수에 정비례해 늘어날 필요가 없어졌습니다. 내부가 덜 알기 때문에 결과는 확장 가능했습니다.

따라서 아키텍처의 물음은 상태가 좋은가 나쁜가가 아니었습니다. 어디에서 정밀함이 비용을 감수할 가치가 있고, 어디에서 집약이 안전하며, 덜 아는 부분의 네트워크가 약속을 하는 부분으로 어떻게 결과를 보고할 것인가였습니다.

빠진 중간 다리는 신호 문제였다

RFC 2990은 DiffServ를 경계 중심이라고 불렀습니다. 이 표현은 운영상의 강점과 불완전한 통제 루프를 동시에 지목했습니다.

경계에서 운영자는 트래픽을 분류하고, 단속하고, 동작 집약으로 수용할 수 있었습니다. 내부에서 라우터는 집약 처리를 효율적으로 전달할 수 있었습니다. 그러나 이 아키텍처는 도메인 내부에서 변화하는 자원 가용성이 경계의 트래픽 조건화 장치에 어떻게 도달하는지 정의하지 않았습니다. 경계는 어제의 가정을 오늘의 혼잡에 그대로 적용하고 있을 수 있었습니다.

또한 이 모델은 경계가 애플리케이션에 원하는 응답을 제공할 수 없다는 사실을 어떻게 알리는지도 정의하지 않았습니다. 애플리케이션은 요청된 서비스가 있어야만 의미가 있는 프로파일을 계속 전송할 수 있었습니다. 프리미엄 클래스 요금을 지불하면서 적응이 너무 늦거나, 그 결과로 생긴 지연을 단말 문제로 오진할 수도 있었습니다.

그래서 RFC 2990은 두 가지 뚜렷이 다른 신호를 요청했습니다.

  1. 코어에서 경계로 전달되는 가용 자원에 대한 보고; 그리고
  2. 경계에서 애플리케이션으로 전달되는 수용 또는 실패에 대한 보고.

이 둘을 하나로 뭉개면 권한 구조가 가려집니다. 내부 측정은 애플리케이션에게 자원을 부여하지 않으면서 경계에 정보를 줄 수 있습니다. 경계의 결정은 애플리케이션이 이후 실제로 경험한 것을 증명하지 않으면서 흐름을 거절할 수 있습니다. 각 전이에는 그것에 맞는 고유한 근거가 필요했습니다.

탐색은 수용보다 앞서야 했다

RFC는 요청이 경계에 닿기도 전에 빠져 있는 또 하나의 단계를 발견했습니다. IntServ와 DiffServ 모두 일반적으로 베스트에포트 라우팅 경로를 전제했습니다. 그 경로가 라우팅 메트릭상 최저일 수 있고, 동시에 애플리케이션이 필요로 하는 서비스 역량을 결여할 수도 있었습니다.

단계별 배포 상황에서는 서비스 가능한 경로가 일반 경로와 공존할 수 있었습니다. 그러나 어느 아키텍처도 애플리케이션이 어떤 후보 경로가 특정 프로파일을 지원할 수 있는지 물어볼 수 있는 견고한 방법을 제공하지 않았습니다. 패킷을 마킹하는 것은 다른 경로를 발견해주지 않았습니다. 이미 선택된 경로에 예약을 거는 것은 그 경로가 최선의 서비스 경로임을 증명하지 못했습니다.

RFC 2990은 이 문제를 QoS 라우팅과 연결했습니다. 유용한 경로 메트릭은 단순히 유휴 대역폭을 세는 것이 아니었습니다. 그것은 낮은 우선순위 트래픽을 다른 곳으로 밀어낼 수 있는지까지 포함하여, 선택된 품질에서 추가 트래픽을 실을 경로의 잠재력을 추정해야 했습니다. 이는 중립적인 미사용 용량 목록이 아니라 정책이 얹힌 대안성의 측정이었습니다.

탐색, 선택, 수용은 세 개의 결정이었습니다. 하나의 코드포인트가 이들을 동의어로 만들 수는 없었습니다.

TCP는 역방향 경로를 드러냈다

문서의 TCP 논의는 일방향 모델에 대한 실용적인 경고를 제공했습니다. TCP 송신자는 돌아오는 확인 응답(ACK)을 이용해 이후 전송의 타이밍을 잡습니다. 전방 데이터가 한 서비스 프로파일을 받는 동안 역방향 확인 응답이 다른 프로파일을 받는다면, 애플리케이션이 체감하는 성능은 양쪽 경로의 결합 결과였습니다.

지터는 확인 응답을 하나의 버스트로 뭉개놓을 수 있었습니다. 송신자는 그에 대한 응답으로 데이터 버스트를 쏟아내어, 자신을 보호하려던 바로 그 서비스 용량에 부담을 줄 수 있었습니다. 대칭 프로파일이 도움이 될 수 있었지만, 그렇다면 아키텍처는 양방향이 어떻게 요청되고 그 자원 사용이 이중 과금 없이 어떻게 계수되는지를 설명해야 했습니다.

이것은 단순한 TCP 세부사항 이상이었습니다. 서비스는 패킷이 자신의 클래스를 달고 있는 지점에서만 평가될 수 없었습니다. 트래픽을 통제하는 피드백은 반대 방향으로, 다른 정책 아래에서 흘러갈 수 있었습니다.

측정이 처리 방식을 주장으로 만들었다

RFC 2990은 자원 측정과 전달 서비스 측정을 구분했습니다.

첫 번째는 수용에 먹여졌습니다. 네트워크가 경로를 따라 안전하게 받아들일 수 있는 것은 무엇인가? 두 번째는 수용 이후의 성능을 검증했습니다. 클라이언트에게 전달된 서비스는 명세에 부합하는가?

양쪽 당사자는 서로 다른 이유로 두 번째 기록을 필요로 했습니다. 운영자는 서비스 주장을 뒷받침할 객관적 근거가 필요했고, 클라이언트는 추가 비용이 더 나은 애플리케이션 성능을 샀다는 근거가 필요했습니다. 큐 설정, 패킷 마크, 성공적인 예약 교환은 관측된 전달을 대신할 수 없었습니다.

이 구분이 중요한 이유는, 서비스 클래스가 결과를 증명하는 대신 요청 자체에 과금하려는 유혹을 만들기 때문입니다. RFC 2990은 프리미엄 요금제와 희소 자원에 대한 수요를 가격으로 조절하는 방식을 예견했습니다. 그러면서도 프리미엄 사용을 특정 클라이언트에 연결할 회계 모델이나 데이터 수집 방법은 아직 정의되지 않았다고 지적했습니다.

완전한 상업 루프에는 최소한 이것이 필요했습니다. 신원, 권한, 요청, 수용, 자원 할당, 관측된 전달, 귀속된 사용, 요금 규칙, 청구서. RFC는 그 사슬을 이미 만들었다고 주장하지 않았습니다. 빠져 있는 고리들을 밝혔습니다.

하이브리드 아키텍처는 인터페이스 계약이었다

같은 달에 발표된 RFC 2998은 IntServ 요청이 DiffServ 영역을 통과할 수 있는 방법을 기술했습니다. RFC 2990은 그 작업을 활용해 하나의 가능한 역할 분담을 보여주었습니다. 경계에서의 흐름 단위 상호작용, 코어에서의 집약 동작.

애플리케이션은 RSVP를 통해 서비스를 요청할 수 있었습니다. 경계 시스템은 그 흐름을 호환되는 DiffServ 집약으로 사상할 수 있었습니다. 코어는 흐름 단위 상태를 피하면서, 더 넓은 경로는 애플리케이션 대면의 예약 대화를 유지할 수 있었습니다.

그러나 집약이 실패를 지워주지는 않았습니다. 높은 정밀도의 단단한 전달 서비스를 위해서는, DiffServ 영역 내부에서의 수용 실패가 애플리케이션까지 전달되어야 했습니다. 가용 집약 용량이 정적이라면 경계에 그 한도를 설정할 수 있었습니다. 가용성이 동적으로 변한다면 코어는 RSVP 환경으로 흘러드는 살아있는 신호를 필요로 했습니다.

따라서 하이브리드는 두 라벨 사이의 마법 같은 호환성이 아니었습니다. 두 가지 다른 진실 모델 사이의 인터페이스 계약이었습니다. 한쪽은 개별 요청을 알았고, 다른 쪽은 집약 용량을 알았습니다. 애플리케이션이 침묵을 성공으로 받아들이기 전에 경계가 이 둘을 조정하고 실패를 돌려보낼 때에만 아키텍처는 성공했습니다.

보편적 아키텍처도, 보편적 영수증도 없었다

RFC 2990은 이질적인 배포를 예상했습니다. 어떤 네트워크는 서비스를 차등화하고, 어떤 네트워크는 그렇지 않을 것입니다. 어떤 메커니즘은 깔끔하게 상호운용되고, 어떤 것은 다리가 필요할 것입니다. 경로들의 서비스 역량이 서로 다를 수 있으므로 가능한 경로의 수는 또 하나의 차원을 얻게 됩니다.

그 다양성은 탐색, 호출, 측정을 똑같이 필수로 만들었습니다. 그리고 하나의 보편적 QoS 아키텍처에 대한 근거를 약화시켰습니다. 결론은 대신 맞춤형 조합을 선호했습니다. 코어 확장성이 지배하는 곳에서는 집약 메커니즘을, 경계 정밀함이 감당 가능한 곳에서는 흐름 단위 메커니즘을.

Lu Heng의 최소 초기 명세(minimum-initial-specification) 관점은 그 결론의 제도적 미덕을 명확히 합니다. 공통 아키텍처는 요청, 용량 사실, 결정, 결과를 교환하는 데 필요한 가장 작은 인터페이스를 정의하는 것으로 충분했습니다. 모든 운영자의 자원 정책을 중앙집중화할 필요는 없었습니다. 지역적 결정은 그 경계가 관측 가능할 때에만 정당했습니다.

현실 계층(reality-layer) 관점은 근거 규율을 공급합니다. 코드포인트는 수용이 아니었습니다. 수용은 용량이 아니었습니다. 용량은 처리가 아니었습니다. 처리는 측정된 애플리케이션 성능이 아니었습니다. 측정은 귀속된 사용량이 아니었습니다. 사용량은 청구서가 아니었습니다.

구현 코드가 루프를 닫아야 했습니다. 그렇지 않으면 네트워크는 거절이라고 말하지 않고 거절할 수 있었습니다.

출처