네트워크에는 대역폭이 있었다. 애플리케이션은 여전히 굶고 있었다: RFC 1453

요약

• RFC 1453은 멀티미디어가 네트워크 안의 대역폭만 필요로 하는 것이 아니라, 호스트를 통해 애플리케이션까지 전달되는 대역폭과 서비스에 맞춘 지연 시간·동기화·오류 및 흐름 정책이 필요하다고 주장했다.
• 이 메모는 XTP를 기능이 풍부한 해법으로 제시했지만, 동시에 그 자체의 한계도 밝혔다. 우선순위만으로는 지연을 제어할 수 없고, 회의 승인은 상위 계층이 결정하며, 애플리케이션·드라이버·운영체제가 병목이 될 수 있다는 점이다.
• 따라서 링크 속도, 전송 계층 기능, 실험실 시연은 근거의 한 계층만 차지할 뿐이다. 사용 가능한 회의는 애플리케이션 경계에서 관찰되어야 하며, 이후의 RTP는 QoS나 시간 내 전달을 스스로 보장하지 않기로 하여 같은 주의를 지켰다.

빠른 링크 옆의 텅 빈 버퍼

RFC 1453이 암묵적으로 시험대에 올려놓은 워크스테이션을 떠올려 보자. 광대역 인터페이스는 불과 몇 년 전만 해도 사치로 보였을 속도로 데이터를 받고 있다. 전송 계층은 패킷을 옮기고 있다. 그런데도 애플리케이션의 재생 큐는 바닥나고, 오디오는 엉뚱한 시점에 도착하거나, 화면은 발화자의 입보다 늦게 움직인다. 이 장면 어디에도 링크가 느려야 할 이유는 없다.

1993년 4월에 발표된 William J. Chimiak의 메모는 네트워킹 언어가 여전히 흐리기 쉬운 구별에서 출발했다. 고성능 하위 계층은 새로운 애플리케이션을 상상 가능하게 만들었지만, 그것을 가능하게 한다는 것은 네트워크 안에 대역폭을 확보하는 것이 아니라 대역폭을 애플리케이션에 전달하는 것이었다. 운영체제가 병목 지점이 될 수 있었다. 전송 구현은 사용자 프로세스가 결코 얻지 못한 처리량을 두고 스스로를 칭찬할 수 있었다.

이것은 "멀티미디어는 속도가 필요하다"는 주장보다 훨씬 까다로운 주장이다. 이것은 측정 경계를 옮긴다. 링크 카운터는 링크에 대한 근거고, 전송 카운터는 전송 계층에 대한 근거다. 어느 쪽도 미디어 애플리케이션이 사용자가 요구하는 조건에서 자료를 받아 스케줄하고 렌더링하기 전까지는 대화를 서술할 권한이 없다.

RFC 1453은 인터넷 표준이 아니라 Informational 문서였다. Xpress Transfer Protocol, 즉 XTP를 설명하는 매개 역할을 자임하기도 했다. 따라서 이 문서는 중립적 판정이 아니라 이해관계가 있는 제안으로 읽혀야 한다. 그 역사적 가치는 부분적으로 이런 개방성에 있다. 선전은 관찰한 문제와 스스로 인정한 한계로부터 분리할 수 있다.

"멀티미디어"는 서로 양립할 수 없는 여러 요구였다

원격 회의는 하나의 트래픽 클래스가 아니었다. 메모가 묘사한 워크숍 시나리오는 가상 공유 작업 공간 안에서 대화형 음성·영상, 멀티캐스트 배포, 파일 및 데이터 전송, 그래픽, 저장된 오디오·비디오, 데이터베이스 질의를 결합했다. 이 활동들은 서로 다른 것을 중시하면서 같은 시스템을 두고 경쟁했다.

대화형 음성 스트림은 늦은 재구성보다 어느 정도의 손실을 더 쉽게 견딜 수 있었다. 파일은 완전성이 필요했다. 데이터베이스 요청은 왕복 지연에 민감했다. 비디오와 오디오는 미디어 내부의 타이밍과 서로 간의 동기화를 둘 다 필요로 했다. 회의에는 또한 제어 평면이 필요했다. 세션을 시작하고, 진행 중인 세션에 합류하고, 다른 모두에게 피해를 주지 않고 나가고, 마지막으로 세션을 종료하는 것이다.

멤버십 모델은 문제를 다시 바꾸었다. RFC 1453은 약 2명에서 15명 사이의 참가자로 이루어진 긴밀하게 통제되는 다대다 회의와, 더 느슨한 일대다 배포를 구별했다. 또한 최소한 일부 보안 질문은 전송 계층 위에 속한다고 관찰했다. 누가 회의에 대한 정보를 찾을 수 있고, 누가 회의에 합류할 수 있는가. 높은 우선순위 표시가 붙은 패킷이 승인된 참가자가 되는 것은 아니다.

이 워크로드를 "비디오 대역폭"으로 환원하면 문제를 어렵게 만들었던 바로 그 요구가 지워진다. 증가가 성공을 보장하는 단일 스칼라는 존재하지 않았다. 시스템은 지연, 지터, 처리량, 손실, 복구, 동기화, 멤버십, 비용 사이에서 협상해야 했고, 서로 다른 메커니즘이 소유하는 계층들에 걸쳐 그렇게 해야 했다.

서비스 품질은 배지가 아니라 요청으로 시작되었다

RFC 1453은 이례적으로 넓은 범위의 서비스 품질(QoS) 기준을 나열했다. 보장된 처리량, 연결 신뢰성, 호출 완료, 끊긴 호출, 허용 가능한 오류, 압축 선택, 동작 아티팩트, 흐름 제어, 지연 시간 등이었다. 그 중요한 아키텍처적 조치는 QoS를 애플리케이션 또는 전송 서비스 사용자가 전송 계층에 입력하는 요청으로 만든 것이었다.

방향이 중요하다. 네트워크가 먼저 자신을 "고품질"이라고 선언하고 애플리케이션에게 그 라벨에 적응하라고 요구한다면, 서비스는 공급자의 보이는 장비에 의해 정의된 것이다. 반대로 애플리케이션이 자신의 작업이 견딜 수 있는 것에서 출발하면, 하위 계층에 경계가 정해진 서비스를 요구할 수 있다. 요청은 거절되거나 약화될 수 있지만, 적어도 불일치는 측정 가능하다.

RFC 1193은 3년 전에 이 클라이언트 관점을 발전시켰다. 지연 상한, 지연 변동 상한, 최소 처리량, 신뢰성 요구를 구별했다. 또한 "보장"이라는 단어에 의도적으로 강한 의미를 부여했다. 명시된 조건 아래에서 클라이언트와 서버 양쪽에 의무가 부과되는 약속이다. 네트워크 운영자가 그 법적 언어를 채택하든 그렇지 않든, 근거적 요점은 남는다. 보장은 형용사가 아니라 측정 기준, 경계, 조건, 구제를 갖춘 주장이다.

이 때문에 "기가비트 링크 하나"는 "회의가 될 것인가"에 대한 빈약한 대답이다. 링크 속도는 호스트가 얼마나 복사하고 스케줄하고 전달할 수 있는지 말해 주지 않는다. 늦게 도착한 패킷이 여전히 유용한지, 오디오와 영상이 하나의 클록을 공유하는지, 버퍼가 고갈되는지, 참가자가 승인되었는지도 말해 주지 않는다. 용량은 서비스의 한 입력이지 서비스 그 자체가 아니다.

XTP는 트래픽 클래스마다 프로토콜을 만드는 대신 조절 장치를 제시했다

RFC 1453은 엔지니어들이 새로운 애플리케이션 클래스마다 새로운 전송/네트워크 조합을 만들고 있다고 걱정했다. 그 대안은 애플리케이션이 정책을 선택할 수 있을 만큼 충분한 메커니즘을 갖춘 통합 프로토콜이었다. 그것이 XTP를 위해 제기한 사안이었다.

제안된 도구 상자는 구체적이었다. 32비트 SORT 필드는 우선순위를 XTP 노드를 통해 전달했다. 선택적 승인, 빠른 부정 승인, 선택적 재전송은 서로 다른 오류 제어 선택을 가능하게 했다. 속도 및 버스트 제어는 흐름 제어와 결합될 수 있었다. 멀티캐스트와 대역 외 전달은 회의의 다른 요구를 다루었다. 부분 오류 제어 연결(Partially Error Controlled Connection)은 시간적 정확성이 완전한 재구성보다 중요할 때 복구 노력을 의도적으로 조절할 수 있었다.

이것은 단순한 유연성 자체를 위한 유연성이 아니었다. 재전송은 손실을 복구하면서도 마감 시간 이후에 도착함으로써 대화형 스트림을 망가뜨릴 수 있다. 모든 복구를 거부하면 지연은 지켜지지만 미디어는 사용 불가능해질 수 있다. 자신의 코덱, 버퍼, 내성을 아는 애플리케이션은 모든 바이트를 똑같이 급하고 똑같이 복구 가능한 것으로 다루는 전송 계층보다 더 나은 절충을 할 수 있다.

이 메모의 가장 강력한 설계 아이디어는 메커니즘과 정책의 분리였다. 연결이 안정적인 메커니즘을 노출한다면, 오류 또는 흐름 정책은 세션을 닫고 새 프로토콜 스택을 구성하지 않고도 변화하는 링크 조건에 적응할 수 있다. 세션은 유지된 채로 그 데이터의 처리 방식이 바뀔 수 있었다.

그러나 RFC 1453은 자신의 메커니즘 주장을 보장으로 만들지 않았다. 문서는 명시적으로, XTP의 우선순위 기능이 그 자체로는 지연을 제어하지 않는다고 말했다. 우선순위는 경쟁의 순서를 정할 뿐, 용량을 만들어내거나 모든 계층의 대기열에 상한을 두거나 애플리케이션을 스케줄하지 않는다. 메모는 또한 애플리케이션들이 XTP만큼 기존 프로토콜로도 만들어질 수 있을 것이라고 인정했다. 이 문장들은 역사의 각주가 아니라, 제안이 신화로 변하는 것을 막는 경계다.

전송 계층은 성공했지만 프로세스는 여전히 실패할 수 있을 때

부분 오류 제어 연결의 예는 호스트 측 문제를 선명하게 만들었다. 이 정책은 수신 FIFO를 굶기지 않으면서 유용한 오류 제어를 최대화하려 했다. 그 균형이 달성되면, 다음 병목은 전송 계층이 아니라 애플리케이션, 드라이버 또는 운영체제의 버퍼 관리가 될 수 있었다.

이것은 측정 질문이 병목과 함께 이동할 때에만 성공이다. 전송 벤치마크는 개선되는 동안 재생은 여전히 불안정할 수 있다. 커널은 패킷을 받으면서 사용자 프로세스는 자신의 스케줄링 기회를 놓칠 수 있다. 프로세스는 프레임을 받으면서 렌더러는 너무 늦게 그것을 제시할 수 있다. 각 계층은 자기 지역 카운터로는 옳지만 서비스에 대해서는 틀릴 수 있다.

따라서 근거 사슬은 한 방향으로 흐른다.

사용 가능한 링크 용량 → 전송 메커니즘 구성 → 호스트 경로가 전달을 지속 → 애플리케이션이 사용 가능한 미디어를 수신 → 세션 요구 충족 → 사용자 경험 관찰

어떤 요소도 왼쪽 요소에게서 증명을 빌릴 수 없다. 구성된 우선순위는 관찰된 지연 상한이 아니다. 비어 있지 않은 커널 소켓은 굶지 않는 애플리케이션 큐가 아니다. 전달된 오디오와 전달된 비디오는 입술 동기화가 아니다. 패킷을 받는 참가자는 그 참가자가 승인되었다는 근거가 아니다.

이것이 하드웨어 설계가 메모에 등장한 이유이기도 하다. RFC 1453은 시스템 인터페이스, VLSI 기법, 병렬 상태 기계, 컨텍스트 전환, 인터럽트 처리가 프로토콜 경제학에 속한다고 주장했다. 아름다운 유선 프로토콜은 메모리 복사, 인터럽트, 구현 경계에서 약속한 이점을 잃을 수 있었다. 제조는 아키텍처보다 아래의 일이 아니었다. 그것은 아키텍처가 감당 가능한 서비스가 되는지를 결정할 수 있었다.

시연은 가능성을 입증했을 뿐, 보편성은 입증하지 않았다

RFC 1453은 여러 인상적인 당대 결과를 보고했다. 버지니아 대학교(University of Virginia)의 실험은 FDDI 위에서 100개가 넘는 시뮬레이션 음성 채널을 운영했다. 메모는 초당 30프레임의 전체 프레임·풀 컬러 비디오를 전달하는 비디오 메일 시연을 묘사했다. NRaD에서의 간단한 멀티캐스트에 대해 약 25밀리초의 마이크에서 스피커까지 지연을 보고했다. 한 상용 사례는 속도 제어를 사용해 스위칭 허브 이더넷 위에서 1.2 Mbps 압축 비디오와 최소 10개의 동시 스트림을 전달했다.

이 주장들은 1993년에 패킷 네트워크가 그런 작업을 감당할 수 없다는 생각에 맞섰기 때문에 의미가 있었다. 네트워크, 호스트, 소프트웨어, 애플리케이션의 특정 조합이 유용한 문턱을 넘을 수 있음을 보여주었다. 그러나 이것들은 설치 기반, 독립적 재현, 일반적인 인터넷 조건, 보편적인 지연 보장을 입증하지는 않았다.

시연은 명시된 경계 안에서만 완전한 사건이다. 이를 일반화하려면 조사자는 하드웨어, 토폴로지, 제공 부하, 코덱, 프레임 정의, 손실 패턴, 스케줄링 정책, 클록 방식, 측정 끝점을 필요로 한다. "초당 30프레임"은 버퍼링이 몇 초를 더한다면 상호작용에 대해 거의 말해 주지 않는다. "25밀리초"는 시작점과 끝점이 알려져 있을 때만 의미가 있다. "100채널"은 명료도를 측정하지 않고 용량만 측정할 수 있다.

규율 있는 역사적 결론은 소박하다. XTP 메커니즘은 이 메모가 회의와 관련 있다고 본 보고된 실험에서 사용되었다. 이 문서는 XTP가 인터넷의 멀티미디어 전송이 되었거나, 그 결과가 그 환경 밖에서도 유지되었다는 것을 증명하지 않는다.

서비스를 실체로 만드는 두 가지 방식

RFC 1453은 XTP와 대조하고자 하는 신흥 아키텍처의 일부로 ST-II를 논의했다. ST-II는 스트림을 명시적인 네트워크 객체로 만들었다. 원점이 생성을 요청하고, 참가자와 중간 에이전트가 참여하고, FlowSpec이 요구를 서술하고, 자원이 예약되며, 대상이 수락할 수 있었다. 멤버십은 바뀔 수 있었고, 장애는 부분적인 해체와 재구성을 촉발할 수 있었다.

이것은 권한 부재 문제에 대한 하나의 대답이었다. 성능 요청을 분산된 네트워크 상태로 바꾸는 것이다. 대가는 설정, 상태, 복구 장치, 참여 에이전트에 대한 의존이었다. XTP의 주장은 달랐다. 더 일반적인 기능 풍부한 전송 계층을 유지하고, 스택 사이를 이동하지 않고도 정책이 변할 수 있게 하는 것이다.

어느 서술도 쉬운 승자를 승인하지 않는다. 예약된 스트림도 여전히 애플리케이션 경계에서 실패할 수 있다. 유연한 전송 계층도 여전히 강제 가능한 종단 간 상한을 결여할 수 있다. 두 아키텍처는 제어를 서로 다른 위치에 두고 서로 다른 복잡성 비용을 지불했다.

이후의 RTP는 애초에 전체 질문을 해결하는 척하지 않았기 때문에 유용한 가드레일이 된다. RFC 3550은 RTP와 RTCP를 실시간 데이터와 전달 모니터링을 위한 종단 간 기능으로 서술한다. 또한 RTP 자체는 자원을 예약하지 않고, QoS를 보장하지 않고, 시간 내 전달을 담보하지 않으며, 전달 자체를 보장하지도 않고, 재정렬을 막지도 않는다고 말한다. 순서 번호와 보고는 관찰 가능성과 재구성 도구를 만들 뿐, 하위 계층 서비스를 창조하지 않는다.

이것은 대비이지, RFC 1453이 RTP를 낳았다는 주장이 아니다. 지속되는 패턴은 이것이다. 프로토콜은 용량과 타이밍 보장을 다른 곳에 남겨 둔 채로 유용한 실시간 의미를 운반할 수 있다. 운영자는 어떤 계층이 어떤 약속을 소유하는지 알아야 한다.

출처와 한계

문서 상태와 편집적 배경은RFC 1453의 RFC Editor 기록으로 확정되며, 문제 제기, XTP 제안, 주의 사항, 보고된 시연은RFC 1453 전문에서 나온다. 클라이언트 측 성능 모델은RFC 1193에 문서화되어 있다. 자원을 지참하는 스트림 아키텍처라는 경쟁 대안은RFC 1190에 나타난다. 이후의 RTP 범위와 비보장 항목은RFC 3550의 RFC Editor 기록과 전문에 서술되어 있다.

이 공식 출처들은 설계, 명시된 요구, 문서 상태, RFC 1453이 경계가 정해진 실험에 대해 보고한 내용을 확정한다. 그러나 이 출처들은 현재의 배포 상황, 벤더 성능, 독립적 재현, 사용자 만족, XTP에서 RTP로의 인과 경로, 현재 어떤 회의의 성공 여부를 확정하지 않는다.