RE: Split error codes in two

[Mike Bishop <[e-mail]>]

Jana and I were discussing this today, and part of the difference comes down to how you conceive of the API a QUIC implementation will expose.  My mental model has been that a stream/stream-pair consists of an InputStream and an OutputStream; you can read on one, you can write on the other.  For the write stream, you can write your data to completion and close the stream, or you can decide to abort writing.  The wire expressions of these are FIN and RST_STREAM, respectively.  For the read stream, you can read the incoming data to the end or you can abort reading and discard the remainder of the stream; the wire expression of this would be flow control updates and STOP_SENDING, respectively.  On the other side, receipt of a RST_STREAM surfaces as a read error and receipt of a STOP_SENDING surfaces as a write error.  (Jana commented that in this mental model it might be clearer to call the frames WRITE_ABORT and READ_ABORT.)

If we take Martin’s proposition that streams only close by application action, there would never be a write error surfaced to the application unless the underlying transport went away entirely.  Instead, it’s the responsibility of the application protocol to communicate (on another stream, in this case) that you should abort writing, even if you’ve already written to completion, and then to do so.  That implies that the application needs the ability to return to streams on which it’s done writing, in case it’s later asked to go back and reset them.

Much of our discussions around unidirectional streams, stream state transitions, etc. including the question of whether STOP_SENDING belongs at the transport layer, stem from the fact that we all have different implicit mental models of the functional surface QUIC exposes.  Perhaps we should take a step back and agree on that first, as I believe Christian has suggested in the past?

From: Jana Iyengar [mailto:[e-mail]]
Sent: Friday, September 8, 2017 5:34 PM
To: Martin Thomson <[e-mail]>
Cc: Subodh Iyengar <[e-mail]>; Mike Bishop <[e-mail]>; Philipp S. Tiesel <[e-mail]>; QUIC WG <[e-mail]>; Nick Harper <[e-mail]>; Victor Vasiliev <[e-mail]>
Subject: Re: Split error codes in two

On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
> I don't think it makes sense to design an app protocol that doesn't send a
> RST in response to a RST.

I've been told not to invoke this particular demon, but you just
invoked the Unidirectional streams problem.  I think that we get there
because of this meme that says that data in the one direction is
somehow necessarily bound to data in the other direction.  That's an
entirely constructed notion.  A useful construct at times, certainly,
but that's not the point here.

I think that's the most common use of a RST -- to close both directions.

So I disagree.  There are many protocols in which you send messages
(== streams) in one direction but not another.  One of the ways you
get into a unidirectional state in the current draft is to end one
side.  A FIN is only one way to do that, a unidirectional RST can be
faster and even superior in other ways.  The HTTP use case clearly
illustrates that.

FIN is the primary way in which half-close is achieved, which is what you're talking about. The HTTP use case is a complete one-off -- STOP_SENDING is an odd enough use case that I'm always left wondering who actually uses it.

Also, as Igor observes, we don't require a reciprocal RST_STREAM in
the current draft.

Yes, we don't. Recall that the RST_STREAM was, prior to the change that doesn't require reciprocity, a bidirectional signal, which was simplified to a unidirectional one, with the general expectation that apps would close the other side when they receive this signal from QUIC. It's surely going to be true of HTTP. It's possible for an app to receive a RST and then keep sending, but that is a use case I haven't seen in practice.