From kazuhooku@gmail.com Thu Oct 12 17:11:26 2023 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97AC1705F0 for ; Thu, 12 Oct 2023 17:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFraq6juFTwF for ; Thu, 12 Oct 2023 17:11:22 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E544C1705EF for ; Thu, 12 Oct 2023 17:11:22 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-9ae75ece209so250891166b.3 for ; Thu, 12 Oct 2023 17:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697155881; x=1697760681; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AOfmRhFrhJvgiFZBQRwaazwxZ0Vn+voloAb9Ef7fE8g=; b=mo+PUhIWDfhHpN6g3SG0ne1tOz6xWnwz11tc4ZVWGwcEunce5eZWHgKXBF10NYSqP0 XqAu9wFwZ30dw4isED+AWLE+f6uU563CBMPBfQ/fjtHUlU6yyULzdVAh1i/M21wUWAUL 3IKbD3/jRVLjTGpOeaHw0veTLyit3F8NQLn1CPC3WmNIU9UIFW3XOdW3PDnGBXA8/ihY 8fz3yn1WXATkGOuDQx6CQFa9sL4N6ilMr4+1EXoau09fjkQStNwpMz9IeCvCr1L0run4 uVwm0ykB+vEg1yRJNMdjEvE2WjpssaO2y93IbTTulB1yXdima6PC2pUZJCQ0RAy8Zycx vvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697155881; x=1697760681; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AOfmRhFrhJvgiFZBQRwaazwxZ0Vn+voloAb9Ef7fE8g=; b=OetJ6cKxyxe9wMk2GY+ukpAQaYoMgMTLyhcyJ2xFE0jOxiAoLkWpDYQLbzAVYxNssq sxx6VoH8vXLjFLg26oUnVRT2PMbyejvs5C8AXKlGSM9NVUV1IymzBS2bzPgahe5wrucj E8N980tF6PoRvAs7R/w9AaREsfz7f55KIbF5MZh4QFsLup3x24DP6XtS6jL5zbFuyifQ UBCqOZvARexo6E/TCHOVXPgMmrkr/QVW39px9Du8DXax19SYJJquMeG8jGkaFLnYjTAf 5yLGlfSQ5nJiPxYH4JQRvZhotCdRA4hF8lj/YsP16WE9k28LnnV+ISbOvJQhhBH4ym2q ZwUA== X-Gm-Message-State: AOJu0YxzCpRrLs2TUju95Rd+cJhmxB5pmY6HzZOG9v6iPxnp2jJ+A18D pU5I/UH+cA2e8F7OooqnsOsmB0skkIvgkJz0EDvxOqSZ X-Google-Smtp-Source: AGHT+IGIlDEMEY8m3//9iHNZjY1R1U81ECEbDMlNTOm1QW8aInwvpkhxtVSq2PpVx4+Ok7OILuWH+5qtUSfMSGHixIQ= X-Received: by 2002:a17:907:7890:b0:9ae:711d:7e03 with SMTP id ku16-20020a170907789000b009ae711d7e03mr23322928ejc.15.1697155880579; Thu, 12 Oct 2023 17:11:20 -0700 (PDT) MIME-Version: 1.0 References: <0304a741-d79d-4ece-9dd7-223e3dba33a0@betaapp.fastmail.com> In-Reply-To: <0304a741-d79d-4ece-9dd7-223e3dba33a0@betaapp.fastmail.com> From: Kazuho Oku Date: Fri, 13 Oct 2023 09:11:08 +0900 Message-ID: Subject: Re: [AVTCORE] Reliable Stream Resets: Requesting a Reset at a Specific Offset To: Martin Thomson Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="00000000000063fa3b06078de581" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2023 00:11:26 -0000 --00000000000063fa3b06078de581 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2023=E5=B9=B410=E6=9C=8811=E6=97=A5(=E6=B0=B4) 10:07 Martin Thomson : > 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=E2=80=AFAM Mathis Engelbart > > 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 readin= g > >> 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 > >> > . This PR > is > >> > based on Martin Thomson's ENOUGH draft > >> > (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 b= e > >> > 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 > > --=20 Kazuho Oku --00000000000063fa3b06078de581 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
2023=E5=B9=B410=E6=9C=8811=E6=97=A5(= =E6=B0=B4) 10:07 Martin Thomson <mt= @lowentropy.net>:
WebTransport could use this, but I doubt that it would need to.<= br>
I'm more concerned about adding another negotiation point for the reque= st.=C2=A0 If they progress in parallel, then we need separate negotiation f= or each and that gets tricky when there is an interdependency like this.

If that is the main concern, I think we m= ight consider changing the Transport Parameter used for negotiating Reliabl= e Reset to take a version number.

Version zero wou= ld indicate that only CLOSE_STREAM can be used. Once we add ENOUGH, we can = increment the version number.

=C2=A0

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. Havin= g
> draft-ietf-quic-reliable-stream-reset and draft-thomson-quic-enough > progress in parallel would avoid this problem and has no clear downsid= e.
>
> David
>
> On Tue, Oct 10, 2023 at 10:55=E2=80=AFAM Mathis Engelbart
> <mathi= s.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 th= at a
>> media frame will arrive too late and will be dropped. RTP over QUI= C 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 s= top
>> reading. However, the receiver can only signal that it wants to fi= nish
>> 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 kee= p 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 tho= se
>> will likely also depend on the dropped frame. Thus, I don't ex= pect 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&#= 39;s only
>> > interested in the first N bytes of the stream, and that it wi= ll 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 o= f the frame
>> > before actually receiving the entirety of it, or in cases whe= re 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/relia= ble-stream-reset/pull/26
>> > <https://github.com/quicwg/r= eliable-stream-reset/pull/26>. This PR is
>> > based on Martin Thomson's ENOUGH draft
>> > (https://datatracker.ietf.o= rg/doc/draft-thomson-quic-enough/
>> > <https://datatracker.iet= f.org/doc/draft-thomson-quic-enough/>).
>> >
>> > Is this mechanism actually useful enough to be included in th= e 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
--00000000000063fa3b06078de581--