search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Constraints on Stream Data section #124

Open LPardue opened 1 year ago

LPardue commented 1 year ago

https://www.ietf.org/archive/id/draft-jholland-quic-multicast-02.html#section-12.1 describes some constraints. And https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/pull/123/files adds even more commentary.

I think the section is mildly problematic. I makes a sweeping claim that applications can't use data if they don't receive it from stream 0, and suggests some server actions based on convenience (which is not well defined), I'm not suggesting these things are wrong.

However, I think the section can be rephrased to make things clearer. For example, imagine an application protocol that sends a infinite series of fixed size atomic data units on the stream, and supports random access of these units. A client that comes late to the stream can easily determine the start of the next unit by looking at the stream offset. Once it's done that, it will just pick up that unit and make progress. A server could retransmit the entirety of the stream before this point, but that might not make sense for the application protocol.

GrumpyOldTroll commented 1 year ago

Yeah, we thought about that a bit. The first version had a concept of a "stream boundary" that was meant to allow this kind of thing, where a receiver could pick up a stream starting at a boundary and assume the data could be interpreted at the app level starting from there: https://www.ietf.org/archive/id/draft-jholland-quic-multicast-00.html#name-mc_channel_stream_boundary_

We decided it adds some complexity and not very much value as compared with just starting new streams as needed, so we dropped it, but if consuming stream id space is an issue it would be possible to bring it back.

GrumpyOldTroll commented 1 year ago

PS: yes, it's kind of looking like consuming stream ids wantonly does cause some complexity. But is it better to allow a stream to start at an offset as though it was offset 0, or is it better to wrestle with the MAX_STREAM issues?

I'm not actually sure yet, but I think we actually have to handle the MAX_STREAM issues regardless, so I'm still leaning toward not adding the new frame with new semantics for starting in the middle.

LPardue commented 1 year ago

That's reasonable. But IMO we shouldn't dictate or declare how application use transport features as heavily as the text implies. I'll prepare a PR that illustrates what I mean