Re: Split error codes in two

[Subodh Iyengar <[e-mail]>]

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.