2023年10月11日(水) 10:07 Martin Thomson <[email protected]>: > WebTransport could use this, but I doubt that it would need to. > > I'm more concerned about adding another negotiation point for the > request. If they progress in parallel, then we need separate negotiation > for each and that gets tricky when there is an interdependency like this. >
If that is the main concern, I think we might consider changing the Transport Parameter used for negotiating Reliable Reset to take a version number. Version zero would indicate that only CLOSE_STREAM can be used. Once we add ENOUGH, we can increment the version number. > > On Wed, Oct 11, 2023, at 07:48, David Schinazi wrote: > > 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 > > <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/avt > > -- Kazuho Oku
