Speaking as a WebTransport enthusiast, I think that this is scope creep, and should be avoided. WebTransport has a dependency on draft-ietf-quic-reliable-stream-reset but has no pressing need for the ENOUGH frame. Adding it would increase the scope of this draft, which would delay shipping it, which would in turn delay WebTransport. Having draft-ietf-quic-reliable-stream-reset and draft-thomson-quic-enough progress in parallel would avoid this problem and has no clear downside.
David On Tue, Oct 10, 2023 at 10:55 AM Mathis Engelbart <mathis.engelb...@tum.de> wrote: > We also discussed this at the AVTCORE interim meeting in September. In > RTP over QUIC, receivers may want to use STOP_SENDING to signal that a > media frame will arrive too late and will be dropped. RTP over QUIC also > uses length fields to signal the length of the next RTP packet, so a > receiver could use an ENOUGH frame to indicate where it wants to stop > reading. However, the receiver can only signal that it wants to finish > reading an earlier frame but will drop the later one. I don't think that > will happen very often because I don't see many reasons to keep reading > older frames if a newer one is already deemed too late. It may be useful > if the earlier frame is a dependency of even later frames, but those > will likely also depend on the dropped frame. Thus, I don't expect it to > be used much in RTP over QUIC. > > On 10/10/23 07:37, Marten Seemann wrote: > > The Reliable Reset draft introduces a CLOSE_STREAM frame that allows > > resetting a stream at a specific offset, thereby guaranteeing the > > reliable delivery of stream data up that offset. > > > > At IETF 117, there was some discussion (mainly in AVT) about whether > > there should be a method for an endpoint to abort reading at a specific > > offset. This would allow an endpoint to communicate that it's only > > interested in the first N bytes of the stream, and that it will discard > > all bytes beyond N. This could be done by introducing a STOP_SENDING > > frame that carries an extra field to carry the value N. > > > > This might be useful if the stream is used to send a sequence of > > (TLV-encoded) media frames, and the receiver knows the size of the frame > > before actually receiving the entirety of it, or in cases where the > > receiver possesses out-of-band knowledge about the frame size. > > > > I created a PR to make this proposal more specific: > > https://github.com/quicwg/reliable-stream-reset/pull/26 > > <https://github.com/quicwg/reliable-stream-reset/pull/26>. This PR is > > based on Martin Thomson's ENOUGH draft > > (https://datatracker.ietf.org/doc/draft-thomson-quic-enough/ > > <https://datatracker.ietf.org/doc/draft-thomson-quic-enough/>). > > > > Is this mechanism actually useful enough to be included in the draft? > > Implementing support for this frame seems quite easy, but it would be > > helpful to learn more about use cases it enables first. > > _______________________________________________ > Audio/Video Transport Core Maintenance > a...@ietf.org > https://www.ietf.org/mailman/listinfo/avt >
