Re: Split error codes in two

[Victor Vasiliev <[e-mail]>]

On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson <[e-mail]>
wrote:

> On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev <[e-mail]>
> wrote:
> > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson <[e-mail]
> >
> > wrote:
> >>
> >> The basic idea here - one that I believe that we have agreement on,
> >> but would like to confirm - is that only applications should be
> >> cancelling streams.  In short: if the transport kills a stream that
> >> the application was relying on, the whole application protocol state
> >> becomes indeterminate.
> >
> >
> > I assume this means only on the wire?  Because you have to close
> > the streams both when your connection goes down, and when you get
> > a 0-RTT reject.
>
> I forget where this discussion happened, but the current thinking was
> that 0-RTT reject doesn't result in streams being closed.  Instead, it
> causes any data that was sent to need to be retransmitted.  Basically,
> treat it as lost (though not for the purposes of congestion signals,
> waves hands a little).  Does that make sense?
>

That is what the current gQUIC code does, and it has been historically
sufficiently problematic that I've been trying to switch us away from that
behavior.  TLS prohibits automatic resend without explicit opt-in from the
application, and even then, it's a bad idea.  Application payload may vary
substantially depending on the state of the TLS connection, so if the
connection changes, client's presented identity, the exporter secrets used,
etc, may become different (and in case of exporter secrets, they will).