GrumpyOldTroll
commented
2 years ago On reflection, I think we should drop the STREAM_BOUNDARY. I think it's either that or add a way to abandon old data on a stream prior to a boundary, but I think this is the same a just making a new stream.
I think it means multicast will consume stream id space an order of magnitude faster than unicast, but that's probably ok, or if it's a problem it can be fixed with a later extension, but probably it's not a problem--stream id space for server-initiated streams would be 2^60-1 I believe, so at 20 streams per second (2 per ABR bit rate, one for the manifest and one for the segment) that would be 1.8 billion years by my calculations, or about 5 months to get to 8-byte stream ids instead of 4-byte stream ids.
So I'm changing the title and pulling out STREAM_BOUNDARY instead.
Good question on what this is and how it's meant to be used from Sam. Rough answer I sent:
It's there because we have shared channels and they might carry streams, and it’s useful to allow the streams to be long-lived. It’s possible (and I think useful) for a client to start processing an in-progress stream starting at the boundary of an HTTP push for instance, or at a message boundary for another higher-layer protocol, but without this stream boundary the client doesn’t know at what byte offset inside the stream it’s safe to start processing data (if a client started trying to parse the stream in the middle of the HTTP push, it wouldn’t know how to interpret it).
In addition to h3 server push (and maybe webtransport?), I think this is useful for the latest moq-related proposals like RUSH (https://datatracker.ietf.org/doc/draft-kpugin-rush/) and WARP (https://datatracker.ietf.org/doc/draft-lcurley-warp/).