search

GrumpyOldTroll / draft-jholland-quic-multicast

Work in progress to propose a multicast extension to quic.
Other
6 stars 6 forks source link

Michaels review - Give more details about the unicast connection #43

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

I have a feeling that more should be said about this unicast connection. Some constraints perhaps… can it migrate? Can it use multiple streams? Can it be used for traffic that’s not bound to the signaling for the multicast stuff here?

Also: here, and in most places, you call it “the unicast connection”, which makes quite clear that there is one only. That’s good! But in some places, it says “a unicast connection” which then confuses me. There IS only one which is associated with this multicast stuff, right?

GrumpyOldTroll commented 2 years ago

There is only one, yes. I agree, "a unicast connection" should be changed to "the unicast connection".

I think there are no restrictions on the unicast connection. It can migrate, it can use multiple streams, it can be used for traffic not bound to the signaling for the multicast stuff. It can be multipath.

The only restriction I know that seems like it has been confusing is the restriction on streams: any byte of data at any offset of a particular stream must be the same no matter where the frame containing that byte of stream data came from.

This might place some operational restrictions on servers that use the same channels, to make sure they individually don't generate any unicast streams that could conflict. (I think they have several mechanisms they can use to ensure that doesn't happen, but I think it's implementation-specific.)

MaxF12 commented 2 years ago

Closed by #60