With no hats, IETF or Google or otherwise: I enjoyed reading this document. I am not particularly knowledgeable about multicast, but found the ideas here to be innovative.
Martin High-level comments: ~~~~~~~~~~~~~~~ - I don't really understand the workflow here, and I wonder if explicit discussion of what you're expecting the application layer to do would be helpful. Let's say a client connects to liveevents.example.com. Say the server has 100 different programs, each with 3 channels corresponding to different data rates. This is a very push-oriented model. The server uses MC_ANNOUNCE, potentially to list all 300 channels. It can't send MC_JOIN to all of them, since that would violate capacity limits, so it has to divine what the client wants. Presumably this is being driven by an application-level request protocol (HTTP or whatever) that allows the server to tell QUIC what channel to push. Is this right? - Relatedly, I don't understand why MC_ANNOUNCE and MC_JOIN have to be different frames. There could be a super-frame that has all of this (in addition to MC_KEY information, though that frame also has to have a separate incarnation for re-keying), which would streamline the client state machine considerably. Put differently, I don't see the value of the "unjoined" state. - I haven't thought it through fully, but I am concerned about the possibility of actual Join/Leave state changes becoming desynchronized with IP-level multicast group joins and leaves. Have you worked through the various combinations of a client misbehaving here, doing one but not the other, and convinced yourselves it'll all be fine? - (4.4) It might be useful for MC_ANNOUNCE or JOIN to have up-to-date stream information; how many streams are open, and what is the highest index. In practice, I don't see how a server could support two channels on one connection unless channels are assigned unique stream ID ranges. It would be useful for MC_ANNOUNCE or JOIN to contain stream information (max number of open streams, highest stream ID) so that the client could update its flow control and make a better decision about joining the channel. - (6) How does the client measure packet loss? It's worth pointing out that there is no receiver packet loss detection mechanism in QUIC, so this has to be invented out of whole cloth. Reading between the lines both here and in the MC_INTEGRITY section, I think you have an implied requirement that servers MUST NOT skip packet numbers in the channel; if so, write that down. - (10.2) I can almost figure out for myself why normal key phase rotation would be insufficient, so that you need MC_KEY, but it would be nice for it to be written down. Straightforward stuff to fix ~~~~~~~~~~~~~~~~~~~ (3) I take it that if MC_LIMITS says that both IPv4 and IPv6 are disallowed, this is a way of turning of multicast capability after having initially advertised it, or vice versa? Or is setting both to zero not allowed? (6) Please specify what frames count against cwnd -- I would imagine everything except MC_ACK. (7 and 10.5) IIUC, it's fine for MC_INTEGRITY frames to be sent on the channel, but it's important that the "root" MC_INTEGRITY frame is sent on the unicast channel. Otherwise, channel A could send MC_INTEGRITY for channel B and vice versa, and I believe that would not be effective against the threat model. (10.1) "Header AEAD algorithm" is a weird way of putting it. It's not an AEAD algorithm; instead RFC 9001 designates an header algorithm (AES-ECB or raw ChaCha20) depending on the AEAD algorithm used for payload protection. - Is it intended for MC_ACK to be any less than once every two packets, or are you take the ack-frequency extension and extend it to MC_ACK? (10.8) "After retiring a channel, the client..." makes it sound like the client sends MC_RETIRE. How about "After receiving MC_RETIRE,..." To add to your explanation about RETIRE_CONNECTION_ID, this frame is sent by the creator of the connection ID, which receives packets with that CID. The valence here is different: the creator of the channel ID is also the sender. Nits ~~~ (5) "Desynchronized Limit Violation" should probably be capitalized and added to the registry. (12.1) If it's convenient for some reason, the server could also send preceding data on that stream on the unicast connection to catch the client up.
