요약

  • SQUAD는 공통 데이터를 멀티캐스트로 공유하되 수신자별 인증과 제어를 위한 QUIC 관계를 남기자는 제안이다.
  • 11월 16일 IETF BoF는 워킹그룹을 만들지 않는다. 요구사항과 근거를 모으지만 헌장 승인이나 프로토콜 선정은 하지 않는다.

매력적인 그림은 간단하다. 송신자 하나, 갈라지는 전달 트리, 많은 수신자. 하지만 그림 밖에 남는 일이 만만치 않다. QUIC 수신자마다 인증된 관계가 필요하다. 누군가는 피드백을 모으고, 손실을 찾아내고, 패킷을 복구하고, 혼잡을 제어해야 한다. 경로나 수신자가 공유 스트림을 더는 받지 못할 때의 처리도 정해야 한다.

SQUAD(Scalable QUIC-Assisted Distribution)가 다루려는 문제가 이것이다. 승인된 BoF 요청은 공통 일대다 데이터에 소스 특정 멀티캐스트(SSM)를 쓰면서, 인증과 제어를 위해 각 수신자와 일반 QUIC 연결을 유지하는 방안을 제안한다. QUIC은 UDP 위의 암호화된 다중화 전송을 정의하며 TLS가 보안 설계에 포함된다. SSM은 수신자가 지정한 출처의 트래픽을 요청하는 모델이다. 두 방식을 나란히 둔다고 조정 문제가 사라지는 것은 아니다.

IETF는 IETF 127에서 11월 16일 SQUAD를 다룬다. 회의 이름이 중요하다. 워킹그룹 구성 목적이 없는 Birds of a Feather 세션이다. 요청서도 이 회의에서 헌장을 승인하거나 프로토콜을 선정하지 않는다고 명시한다. 공동 사용 사례와 요구사항을 찾고, 의견이 갈리는 가정을 드러내며, 필요한 실험과 후속 작업을 정하는 자리다. BoF가 문을 열 수는 있어도 제안을 조용히 인터넷 표준으로 바꾸지는 않는다.

‘확장성’이라는 표현보다 미해결 질문이 쟁점을 더 잘 보여준다. 수신자 피드백을 합치면서 장애 경로를 가리지 않을 수 있는가? 일부 수신자만 겪은 손실은 어떻게 복구할까? 용량이 다른 경로가 같은 전송을 받을 때 혼잡은 어떻게 제어할까? 느리거나 악의적인 수신자가 전체 서비스를 흔들지 못하게 할 방법은 무엇인가? 멀티캐스트를 쓸 수 없을 때 수신자별 유니캐스트로 언제 돌아갈까?

이 질문은 송신자와 네트워크 사이에서 일을 옮긴다. 유니캐스트는 송신자가 데이터를 반복하게 하지만 연결별 상태를 볼 수 있다. 공유 멀티캐스트 경로는 적절한 링크에서 중복 트래픽을 줄일 가능성이 있지만, 여러 수신자의 전달 상태와 예외를 조율해야 한다. 수신자별 QUIC 관계를 남기는 것은 공통 페이로드를 공유하면서 각자의 신원과 제어를 보존하려는 시도다. 이 분리가 유용한지는 트래픽과 네트워크에 달려 있다.

기존 표준은 부품을 제공할 뿐 완성품은 아니다. RFC 9000은 QUIC 기본 전송을, RFC 9001은 QUIC의 TLS 사용을, RFC 9221은 QUIC DATAGRAM을 정의한다. RFC 4607은 SSM 서비스 모델을 설명한다. RFC 7450의 AMT는 멀티캐스트를 기본 지원하지 않는 네트워크 구간을 통과하는 방법을 다룬다. 어느 문서도 SQUAD 성능을 측정하거나 사업자 도입을 입증하지 않는다.

11월의 유익한 결과는 프로토콜 발표처럼 극적이지 않을 수 있다. 문제 범위를 좁히거나, 검증 가능한 요구사항을 정하거나, 미해결 과제가 새 워킹그룹을 만들기엔 너무 넓다고 판단할 수 있다. 그것도 진전이다. 표준화 회의는 누군가 그림을 비용 절감으로 포장하기 전에 남은 일을 드러내야 한다.

확인한 1차 자료에는 배포나 성능 비교 측정이 없다. 관리형 네트워크에서 유니캐스트와 비교한 반복 가능한 시험이 나오면 잠재 절감에 대한 판단이 달라질 수 있다.

자료: 승인된 SQUAD BoF 요청서; IETF 127 신규 주제; RFC 9000, RFC 9001, RFC 9221, RFC 4607, RFC 7450.