RE: Split error codes in two

["Lubashev, Igor" <[e-mail]>]

> I don't think it makes sense to design an app protocol that doesn't send a RST in response to a RST


Currently, the transport spec does not require RST_STREAM in response to RST_STREAM. It treats RST_STREAM like STREAM-with-FIN-except-don't-expect-transmittions (and it allows the receiver to drop buffered data not yet delivered to the application, although I would be very careful with that if the library API provides "peek" or "getAvailableDataSize" functions).

I can think of a number of applications for which send-data-after-receiving-RST is a natural design alternative. For example, you can have a print sever that talks to a printer via QUIC with a stream-per-job. Once the server-to-printer stream direction is closed (normally or job aborted via RST), the printer may wish to tell the server how many actual pages were printed by that job.

-----Original Message-----
From: Jana Iyengar [[e-mail]]
Received: Thursday, 07 Sep 2017, 7:43PM
To: Subodh Iyengar [[e-mail]]
CC: Mike Bishop [[e-mail]]; Philipp S. Tiesel [[e-mail]]; Victor Vasiliev [[e-mail]]; QUIC WG [[e-mail]]; Martin Thomson [[e-mail]]; Nick Harper [[e-mail]]
Subject: Re: Split error codes in two

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]<mailto:[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]<mailto:[e-mail]>> on behalf of Jana Iyengar <[e-mail]<mailto:[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.