2023年7月22日(土) 15:24 Marten Seemann <[email protected]>:
> RFC 9443 defines how to demultiplex QUIC from a whole range of other > protocols. Packets in the range 128..191 (i.e. all packets starting with > 0b10xxxxxx) are supposed to be forwarded to RTP/RTCP. > > This mostly works, since QUIC v1 packets (both short and long header) > define the "QUIC bit", the second bit (0x40) to be set to 1. On the other > hand, Version Negotiating packets are defined as 0b1xxxxxxx, where the last > 7 bits are an arbitrary value. RFC 8999 defines these bits as unused, and > it's up to the server to decide how to set these bits. Specifically, it's a > valid strategy to set them to a fixed value. If that value starts with a 0, > Version Negotiation packets would be consistently mis-classified as RTP > packets. > > Section 17.2.1 of RFC 9000 says that servers SHOULD set the first of the > unused bits to 1 "where QUIC might be multiplexed with other protocols". > This advice is fine for some deployments, but in the general case, the > server has no way of knowing what other things the client is demultiplexing > on the same UDP socket. > I actually think that this "where QUIC might be multiplexed other protocols" could be an error in RFC 9000. FWIW, this condition was introduced very late, in https://github.com/quicwg/base-drafts/pull/4744. I think what we really wanted to mean here is "unless an endpoint knows that the peer is not demultiplexing." > I see two ways out here: > > 1. Change the recommendation in RFC 9000 to always set 0x40 to 1 (e.g. > by removing the "where QUIC might be multiplexed with other protocols" > subclause). It might also make sense to add this recommendation to RFC > 8999, too. > > Reading discussions in the past, WG has decided intentionally to scope the classification design to v1 instead of making it an invariant. I think that the choice was correct; as new protocols are deployed and old protocols become extinct, the logic for classification changes. > > 1. Change the classification logic in RFC 9443, such that 128..191 are > only routed to RTP/RTCP if the next 4 bytes are not equal to 0. I'm not > sure about the implications for RTP/RTCP though. > > -- Kazuho Oku
