Re: new draft: RELIABLE_RESET_STREAM

[Kazuho Oku <[e-mail]>]

I know it's been long since we discussed this proposal last time, but I
would like to point out that we did discuss about the same problem during
the development of HTTP/3; see
https://github.com/quicwg/base-drafts/issues/3300.

The argument there (by me) was that it would be helpful for HTTP/3 server
to have a way of resetting streams reliably (like the one proposed by
Marten's draft), because it allows an intermediary to forward an abrupt
close of an HTTP message exactly the way the intermediary received.

So yes, there is a use case for HTTP/3 as well for this proposal.


2022年9月27日(火) 3:45 Matt Joras <[e-mail]>:

> Hi Marten,
> (no hats worn)
>
> The problem this is solving for WebTransport is real, and it's definitely
> tricky. That being said, solving this by complicating the stream semantics
> of a reset feels somewhat unpalatable to me. Today the semantics of the
> reset are straightforward, whereas this introduces complexity for both the
> sender and the receiver in juggling things in this "pending" state.
>
> I am wondering if a simpler solution would be adding a new type of
> RST_STREAM frame which carries auxiliary application information. For
> example, if the application could encode the application stream type in
> this auxiliary information then the reset itself (and its API communicating
> with the application) would completely encode the necessary information for
> the application, without having to make any changes to stream state.
>
> Matt Joras
>
> On Fri, Sep 23, 2022 at 6:21 AM Marten Seemann <[e-mail]>
> wrote:
>
>> Hi Mirja,
>>
>> > I guess my question is more what would you do with this information
>> then if the stream is already closed?
>>
>> This might sound pedantic, but the stream is not closed. The *send
>> direction* of the stream is *reset* according to
>> https://datatracker.ietf.org/doc/html/rfc9000#section-3.1. The *receive
>> direction* of the stream is still open, and there are now many different
>> ways how the peer might react to that situation.
>> To stick to the canceled file upload example, the server may send a HTML
>> page "The upload was canceled. Please try uploading again." on its side of
>> the stream before closing it. Obviously, setting a HTTP payload doesn't
>> make any sense on a WebTransport stream (there might be a WebTransport
>> session using the same underlying QUIC connection!), so it's imperative to
>> know where the stream belongs. The same reasoning applies when
>> multiple WebTransport sessions share the same QUIC connection.
>>
>> > Also in your case of know the session ID, this seems like a complicated
>> hack. Because if you anyway have to change something in the quick stack,
>> wouldn’t it be sufficient to just create a new interface to expose the
>> session ID given it should be known by the QUIC stack, no?
>>
>> This is exactly the problem that RELIABLE_RESET_STREAM solves: The QUIC
>> stack doesn't necessarily know the Session ID. If the STREAM frame carrying
>> the Session ID is declared lost after the stream was reset (using the
>> regular QUIC RESET_STREAM frame), the sender's QUIC stack won't retransmit
>> it. It's totally possible that all that the receiver receives regarding
>> this stream is the RESET_STREAM frame, and no STREAM frames at all.
>>
>> Cheers,
>> Marten
>>
>>
>> On Fri, Sep 23, 2022 at 3:53 PM Mirja Kuehlewind <
>> [e-mail]> wrote:
>>
>>> Hi Martin,
>>>
>>>
>>>
>>> thanks for your reply. Please see below.
>>>
>>>
>>>
>>> *From: *Marten Seemann <[e-mail]>
>>> *Date: *Friday, 23. September 2022 at 12:24
>>> *To: *Mirja Kuehlewind <[e-mail]>
>>> *Cc: *QUIC WG <[e-mail]>
>>> *Subject: *Re: new draft: RELIABLE_RESET_STREAM
>>>
>>>
>>>
>>> Hi Mirja,
>>>
>>>
>>>
>>> > 1. How can you guarantee that any data can be delivered reliably if
>>> the sender is indicating that it won’t retransmit?
>>>
>>>
>>>
>>> That's the new semantics of the RELIALBE_RESET_STREAM frame. Sending
>>> one indicates that you'll reliably retransmit everything up to the
>>> "Reliable Size" byte offset. You don't retransmit anything after that
>>> offset.
>>>
>>>
>>>
>>> > 2. If the sender sends the reset before any stream data is ever
>>> delivered to the application, why do you still need to deliver the session
>>> id (given the stream will never be used)? Or maybe asked differently, why
>>> is the sender sending a reset at all?
>>>
>>>
>>>
>>> I'm not sure I understand the question. In general, you send a
>>> RESET_STREAM (or RELIABLE_RESET_STREAM) because you changed your mind after
>>> you started transmitting data. A standard example from the HTTP world is
>>> that the user starts the upload of a large file, and then cancels that
>>> upload. For WebTransport it depends on your application protocol.
>>>
>>> The reason you want to associate the stream with the correct session is
>>> that the semantics of a stream reset might differ depending on the
>>> application protocol: The server might respond differently to a HTTP/3
>>> stream being reset vs. a WebTransport stream being reset (or even: a
>>> WebTransport stream being reset for Session ID 1 and Session ID 2). We have
>>> this problem since a single QUIC connection can handle HTTP/3 streams and
>>> WebTransport streams for multiple WebTransport sessions at the same time.
>>>
>>>
>>>
>>> I guess my question is more what would you do with this information then
>>> if the stream is already closed?
>>>
>>>
>>>
>>> Also in your case of know the session ID, this seems like a complicated
>>> hack. Because if you anyway have to change something in the quick stack,
>>> wouldn’t it be sufficient to just create a new interface to expose the
>>> session ID given it should be known by the QUIC stack, no?
>>>
>>>
>>>
>>> Mirja
>>>
>>>
>>>
>>>
>>>
>>> Does that answer your questions?
>>>
>>>
>>>
>>> Cheers,
>>> Marten
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 20, 2022 at 7:16 PM Mirja Kuehlewind <
>>> [e-mail]> wrote:
>>>
>>> Hi Martin,
>>>
>>>
>>>
>>> just two quick questions because I’m not sure I fully understand the
>>> proposal/scenario:
>>>
>>>
>>>
>>> 1.      How can you guarantee that any data can be delivered reliably
>>> if the sender is indicating that it won’t retransmit?
>>>
>>> 2.      If the sender sends the reset before any stream data is ever
>>> delivered to the application, why do you still need to deliver the session
>>> id (given the stream will never be used)? Or maybe asked differently, why
>>> is the sender sending a reset at all?
>>>
>>>
>>>
>>> Mirja
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *QUIC <[e-mail]> on behalf of Marten Seemann <
>>> [e-mail]>
>>> *Date: *Friday, 9. September 2022 at 10:35
>>> *To: *QUIC WG <[e-mail]>
>>> *Subject: *new draft: RELIABLE_RESET_STREAM
>>>
>>>
>>>
>>> In RFC 9000 we defined a RESET_STREAM frame. When a stream is reset, the
>>> receiver may deliver the reset error to the application immediately. On the
>>> sender side, lost STREAM frames won't be retransmitted.
>>>
>>> When building applications on top of QUIC, it is a common pattern to
>>> send some kind of identifier (an ID or a string, for example) first, to
>>> allow the application to route the stream to a subpart of that application.
>>> For example, WebTransport sends the Session ID of the WebTransport Session.
>>> Outside of the IETF, I've used something similar for layering various
>>> applications on top of QUIC.
>>>
>>>
>>>
>>> When a stream is reset, the receiver might end up unable to associate
>>> the stream with the respective subpart of the application. This is
>>> problematic, since
>>>
>>> 1.       depending on the application protocol, a reset of a stream
>>> might carry application-layer semantics, and
>>>
>>> 2.       the RESET_STREAM only closes one side of the stream, and it
>>> might depend on the (sub-) application how the other direction of the
>>> stream is handled
>>>
>>> This problem is not unique to WebTransport, but occurs for every
>>> application using some kind of stream identifier. It might make sense to
>>> design a solution at the QUIC layer.
>>>
>>>
>>>
>>> I've just submitted a draft that aims to solve this problem:
>>> https://datatracker.ietf.org/doc/draft-seemann-quic-reliable-stream-reset/
>>>
>>> It defines a RELIABLE_RESET_STREAM frame, which is essentially
>>> a RESET_STREAM frame with one additional field, the Reliable Size. The
>>> sender of the RELIALBE_RESET_STREAM frame commits to (re-)transmitting
>>> stream data up to the Reliable Size reliably, and the receiver delivers
>>> data up to that offset to the application before surfacing the reset error.
>>>
>>> In WebTransport, you'd set the Reliable Size such that it covers
>>> everything up the Session ID, thereby making sure that any stream can
>>> always be routed to its WebTransport session.
>>>
>>>
>>>
>>> Obviously, there are use cases for this draft beyond the reliable
>>> transmission of just a stream identifier. One could imagine an application
>>> protocol that would benefit from being able to have the first part of an
>>> actual application-layer message being delivered reliably. I'm happy about
>>> enabling those use cases, but I've avoided making this draft more
>>> complicated than necessary by accommodating the more general cases.
>>>
>>>
>>>
>>>

-- 
Kazuho Oku