Re: Split error codes in two

[Jana Iyengar <[e-mail]>]

On Thu, Sep 7, 2017 at 7:50 PM, Martin Thomson <[e-mail]>
wrote:

> On Fri, Sep 8, 2017 at 9:42 AM, Jana Iyengar <[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.