Re: Split error codes in two

[Jana Iyengar <[e-mail]>]

So, a RST_STREAM is supposed to be an indication that everything about the
stream is gone or going away. A sender of a RST_STREAM may not deliver data
pending on that stream up to the application, so I don't think it makes
sense to design an app protocol that doesn't send a RST in response to a
RST.

But this brings up an interesting issue: Here we have transport behavior
that requires a particular application behavior, which I'm not a fan of. It
may make sense to require the transport to send a RST in response to a RST,
with a special error code that means "sent in response to a received RST".
That ought to make the semantics of RST clear to apps.

On Thu, Sep 7, 2017 at 4:25 PM, Subodh Iyengar <[e-mail]> wrote:

> If an app wanted to send both the stop sending and the reset stream, would
> it have to wait till stop sending was sent on the wire before sending reset
> streams? For example a API might reasonably be something like
>
>
>    transport->write(StopSendingFrame)
>
>    transport->reset();
>
>
> If the app calls reset, then the transport might dump all data associated
> with the stream immediately so the stop sending might never even be sent.
>
>
> How do people intend to use stop sending from the app protocols that don't
> send RST in response to RST?
>
>
> Subodh
> ------------------------------
> *From:* QUIC <[e-mail]> on behalf of Jana Iyengar <
> [e-mail]>
> *Sent:* Thursday, September 7, 2017 12:02:27 PM
> *To:* Mike Bishop
> *Cc:* Philipp S. Tiesel; QUIC WG; Martin Thomson; Nick Harper; Victor
> Vasiliev
> *Subject:* Re: Split error codes in two
>
>
>> I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it's
>> the wire expression of a read_close(), just as RST_STREAM is the wire
>> expression of a write_close().  If we'd gone the advisory route, it would
>> be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP
>> layer.)  However, if we think other applications aren't ever going to want
>> to close a read stream....
>
>
> TCP allows for read_close() with shutdown(socket, RD), and it basically
> means that TCP will send a RST to subsequent incoming data on that socket
> from the peer. The expectation is that the application knows to not send
> data to a peer that has issued a read_close().
>
> What we're talking about here is different than a read_close(), since it's
> an instruction to the peer to stop sending. This is only useful if I don't
> want to stop sending but want only the peer to stop sending.... and the
> driving use case was RST_STREAM(NO_ERROR) in HTTP/2. I still find that use
> case odd, but I don't know that there's really a need for this otherwise.
> I'm not very married on this point, but I'm wary of providing a knob that
> really doesn't have a strong use case.
>
>