Re: Split error codes in two

[Jana Iyengar <[e-mail]>]

I think this (0-RTT) is a non-issue, but correct me if I'm wrong. This is
really about sending RST_STREAMs, not about anything else. I agree with
Victor and Nick that 0-RTT data cannot simply be retransmitted, but I think
this set of PRs is really about the wire protocol. The way I read it, QUIC
should never be sending RST_STREAMs of its own accord; that should be an
application-controlled mechanism. And to be clear, the only place that's
not true in gQUIC is when a RST_STREAM is received. gQUIC responds
immediately with a RST_STREAM.

In the current draft, we've already changed that requirement: the
application is expected to generate a RST_STREAM in response to a received
RST_STREAM. That leaves the transport requirement of responding with a
RST_STREAM to a STOP_SENDING. I believe STOP_SENDING really is an HTTP-ism
and belongs in HTTP. A transport that wants to throttle the sender on a
particular stream can use flow control to do it.

I think reducing error code space is innocuous, and I'm fine with it.

On Tue, Sep 5, 2017 at 5:07 PM, Nick Harper <[e-mail]> wrote:

> The approach of treating rejected 0-RTT data like it was lost and
> retransmitting at the transport layer causes problems. As Victor
> mentioned, one of the problems is that the exporter secret changes,
> which is a problem for Token Binding if a client attempts 0-RTT Token
> Binding and 0-RTT is rejected. In this case, the Token Binding HTTP
> header needs to be rewritten to be a signature over the new exporter
> value, when the original stream had a Token Binding header that
> covered the old exporter value. I agree with Victor that on 0-RTT
> reject, streams should be closed.
>
> On Tue, Sep 5, 2017 at 4:31 AM, Victor Vasiliev <[e-mail]>
> wrote:
> > 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).
>
>