What *is* a multicast session?

[MaxF12]

I am confused about what a multicast session actually is. Section 2:

A multicast session (or just session) is a one-way communication stream

So is it just a (special) QUIC stream? If so, does Session ID in 9.2 just mean stream ID?

But if it is just a stream, what is the point of the Max Streams field in MC_SESSION_PROPERTIES (and why is it mutable)?

[GrumpyOldTroll]

It's a one-way analog of a connection, the session id replaces the connection id in the 1-rtt packets. The intent is that streams and datagrams can be carried within a packet for a multicast session, just as they can be carried in a connection.

I see now that you've quoted it that "one-way communication stream" is a bad phrasing since it collides with "stream". Maybe "one-way analog of a QUIC connection" would be a better phrasing?

[MaxF12]

Ok, if it is the analog of a connection I am quite confused about how the interaction between the two (or more) will actually look like. Who creates the session, the unicast connection? If its a connection analog wouldn't it have to go through a handshake? Wouldn't this also require a pretty significant API between the connection and the session?

In my mind I always imagined everything living in the same connection and the multicast data would just be on a one directional stream. The server would initiate the stream(s) after learning from the client what its limits are. It would then send a frame (e.g. MC_SESSION_PROPERTIES) over that stream using unicast. That frame would then trigger the client to issue an IGMP/MLD join. From there on the data received via multicast would be pipelined into the stream, processed(decrypted, integrity checked) and then delivered to the application. Though I am sure there are good reasons I have missed that would prevent it being done this way.

[GrumpyOldTroll]

I was thinking about this a bit more. "Analog to a connection" is wrong, you're correct. I'll try again:

I think maybe it's a unidirectional network path that can be shared by multiple connections.

The session id uses the same slot in a packet as a connection id does, and it's used in a similar way as a connection id is used, to link packets received to a connection.

I don't think it's a one-directional stream (in the quic usage of the term "stream") because many one-directional streams can exist on the same network path. (For instance, it's fairly common when using quic to send one object per stream.)

But everything else you described I think matches my intent (except I separated the JOIN from the PROPERTIES as separate frames): From the receiver's point of view, all the data received from the session is part of the single same connection with the server. When a packet is received it's decrypted and integrity checked, then the frames in the packet are processed as any other frames in the connection--any STREAM frame received will get data passed to the application immediately if it's in-order for the stream (otherwise if there are gaps that stream will have to wait for retransmit, though other streams can progress). Any DATAGRAM frame causes immediate delivery of application data. Other kinds of (permitted) frames influence the connection as appropriate (e.g. PATH_CHALLENGE causes a MC_PATH_RESPONSE, PING will cause an MP_SESSION_ACK over unicast even if there wasn't application data, etc.)

Does that help any? It's probably important to get this point clear, thanks for digging on it.

[MaxF12]

That does clear things up, thanks. The part I am still not sure about is why there is a need for the multicast session abstraction? Maybe stream is the wrong abstraction as well, maybe it is just another path as described in multipath-quic? I guess I am still missing something somewhere...

[MaxF12]

Nvm, I just read your PR and it looks like we agree that it is another path

[GrumpyOldTroll]

Closed via https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/pull/8