Re: [AVTCORE] Reliable Stream Resets: Requesting a Reset at a Specific Offset

2023年10月11日(水) 10:07 Martin Thomson <mt@lowentropy.net>:

> 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
> > <mathis.engelbart@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
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
>
>

-- 
Kazuho Oku