MASQUE 압축은 경로 MTU를 키우지 않는다

요약

10월 28일자 MASQUE 작업반 초안 02판은 HTTP에서 알리는 mtu를 수신자가 복원 뒤 받아들일 패킷 크기의 상한으로 정의한다. 압축된 QUIC DATAGRAM 프레임은 상대의 프레임 크기 제한을 지켜야 하고, HTTP/3·QUIC·UDP·IP 부담을 더한 바깥 IP 패킷은 현재 경로 MTU 안에 들어야 한다.
원래 크기가 같은 패킷도 압축 뒤 길이는 다를 수 있다. 5.1.5절은 PMTU 탐색 패킷 하나가 통과했다는 사실을 같은 원래 크기의 모든 패킷으로 확대하지 않는다. 터널 MTU를 정할 때는 압축하지 않은 패킷까지 포함해 공유 트래픽에서 가장 작은 압축 이득을 고려하라고 권한다.

1500이라는 숫자는 수신자의 약속이다

http-datagram-contexts 헤더에 mtu=1500이 적혀 있으면 터널 설정에 그대로 옮기기 쉽다. 초안에서 이 값은 수신자가 처리 컨텍스트를 모두 적용한 뒤 재구성된 패킷을 어디까지 받아들일지 정한다. 발신자는 반복되는 바이트를 템플릿으로 덜어내고, 길이나 체크섬 일부를 수신자가 계산하게 만들 수 있다. 상대는 빠진 부분을 되살린 후 원래 프로토콜로 패킷을 넘긴다. 숫자 1500은 그 결과물의 상한이다.

능력 교환은 방향마다 다르다. 각 끝점은 자기가 받아서 유지할 템플릿, 파생 필드, 체크섬 처리 능력을 알린다. 상대가 알리지 않은 방식으로 컨텍스트를 만들 수 없다. 초안의 예시에서는 양쪽 모두 mtu=1500을 보내지만 파생 가능한 필드와 체크섬 능력은 다르다. 같은 숫자를 발표했다고 두 장치의 처리가 같아지는 것도 아니고, 사이 경로가 같은 폭을 갖는 것도 아니다.

01판에도 복원 뒤 패킷이 상대가 알린 크기를 넘지 못한다는 규칙은 있었다. 02판은 그 규칙의 주인을 더 또렷하게 적었다. mtu는 수신자의 한도이며, 경로 MTU를 잰 결과도 같은 크기의 패킷이 QUIC DATAGRAM 프레임에 들어간다는 보장도 아니다. QUIC DATAGRAM 프레임, DATAGRAM Capsule, 압축 컨텍스트를 쓰지 않는 전송 모두 복원 크기 제한을 받는다. 운반 방식만 바꿔 수신자의 용량을 늘릴 수는 없다.

경로는 압축 후의 몸집을 본다

압축 자체는 쓸모가 있다. CONNECT-IP 같은 HTTP 데이터그램 사용법에서는 흐름이 이어지는 동안 헤더의 많은 바이트가 반복된다. 템플릿은 고정 부분을 생략하고, 파생 필드는 수신자가 길이와 체크섬을 다시 계산하게 한다. 원래 형태로는 QUIC DATAGRAM 프레임에 들어가지 않던 패킷이 압축 뒤에는 들어갈 수 있다. 다만 그 이득은 해당 패킷의 내용과 선택한 컨텍스트에 붙어 있다. 다음 패킷의 필드가 달라지면 덜 줄어든다.

02판에 새로 들어간 5.1.5절은 압축이 끝난 뒤 두 가지 크기를 검사한다. 실제 QUIC DATAGRAM 프레임은 상대가 허용한 프레임 한도를 넘지 않아야 한다. HTTP/3, QUIC, UDP, IP 바깥층을 더한 IP 패킷은 현재 경로 MTU 안에 들어야 한다. 복원하면 1500바이트인 패킷도 보내는 모습이 충분히 작으면 통과한다. 반대로 수신자의 상한보다 작은 패킷도 맞는 컨텍스트가 없거나 압축이 약하면 전송 한도를 넘을 수 있다. 수신자는 완성품을 받아 둘 수 있지만 그 완성품을 만들 재료가 오는 길은 좁을 수 있다.

PMTU 탐색이 여기서 헛된 자신감을 줄 수 있다. 초안은 압축 결과가 원래 크기가 같은 패킷 사이에서도 다르며 탐색 패킷과 일반 트래픽 사이에서도 달라질 수 있다고 적는다. 탐색 성공은 그때 그 컨텍스트로 만들어진 전송 패킷의 통과를 보여 준다. 다른 흐름의 패킷까지 보증하지 않는다. 여러 흐름이 서로 다른 컨텍스트를 쓰면서도 PMTU 상태를 공유할 수 있다는 문제는 RFC 8899와 함께 언급된다. 압축이 잘되는 흐름의 성적을 공용 MTU로 옮기면 압축이 안 되는 흐름이 비용을 낸다.

따라서 5.1.5절은 터널 MTU를 선택하거나 안쪽 트래픽에 PMTU를 알릴 때, 그 숫자를 공유하는 트래픽에서 얻을 수 있는 가장 적은 압축 이득을 계산에 넣으라고 권한다. 압축을 전혀 쓰지 않는 패킷도 포함한다. 잘 압축되는 특정 흐름에 별도의 컨텍스트와 별도의 측정값을 줄 수는 있다. 모두에게 하나의 크기를 약속하려면 가장 잘 접히지 않는 패킷이 기준선에 있어야 한다.

안정적인 우회로가 경고를 지울 수 있다

압축 후에도 QUIC DATAGRAM 프레임에 너무 큰 데이터그램은, 기반 프로토콜이 허용하면 여러 전송 패킷에 걸친 DATAGRAM Capsule로 보낼 수 있다. 초안은 그 값을 정확히 적는다. 안정적인 전달을 얻는 대신 앞선 데이터가 막히면 뒤도 기다리는 현상, 추가 버퍼, 재전송, QUIC DATAGRAM 프레임과의 순서 차이가 생길 수 있다. 원래 데이터가 도착하더라도 지연과 순서의 조건이 바뀐다.

우회가 항상 좋은 소식인 것도 아니다. 5.1.5절은 CONNECT-IP 10.1절과 CONNECT-UDP 6.1절을 가리킨다. 이 문서들은 큰 패킷을 조용히 Capsule로 갈아 태우기보다 버리고 ICMP Packet Too Big을 보내도록 권한다. 안쪽 발신자가 다음 패킷 크기를 조정할 정보를 주기 위해서다. Capsule은 한 번의 전달을 살릴 수 있지만 데이터그램 경로의 한계를 안쪽 트래픽에서 보이지 않게 할 수도 있다. 경로 MTU나 수신자의 복원 한도 자체는 바뀌지 않는다.

Datatracker는 02판을 MASQUE 작업반의 활성 Internet-Draft로, IESG 상태를 I-D Exists로 표시한다. 자료에는 실제 터널의 패킷 기록이나 손실률 측정값이 없다. 같은 원래 크기의 패킷 두 개를 다른 컨텍스트로 보내고, 각각의 압축된 프레임 길이, 바깥 IP 길이, 현재 경로 MTU, Packet Too Big 응답을 기록하면 구현이 어느 문턱에서 실패하는지 알 수 있다. 필요한 증거는 “탐색 성공” 한 칸보다 길다.