Review of draft-jholland-quic-multicast-02

[Martin Duke <[e-mail]>]

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.