Subject: Rejecting 0-RTT (was Re: Split error codes in two)

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Sep 2017 11:05:25 +1000

On Wed, Sep 6, 2017 at 10:07 AM, Nick Harper <[email-masked]> 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.

OK, that's two arguing against continuing.

Given that TLS recommends "starting over", I think that I'd prefer
that to saying that streams close.

That is, if 0-RTT is rejected, you treat the connect as a new one
(stream 0 is again special here, which leads me to question - again -
the wisdom of our design there, but that's a separate problem).  That
way you initiate all application actions as if the connection were
brand new.

Also, you can't close stream 1.

https://github.com/quicwg/base-drafts/issues/761

The only question I have there is what we need to tell the congestion
controller.  Obviously all that 0-RTT won't get acknowledged, but you
can't really pretend that you didn't send it at all, you also can't
mark all those packets as lost either.

https://github.com/quicwg/base-drafts/issues/762

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 6 Sep 2017 06:14:11 +0200

> https://github.com/quicwg/base-drafts/issues/762

Probably that this means the protocol needs to have explicit provisions
for ignored/rejected data, which are data properly delivered by the
transport layer but rejected by the application. I don't know what it
implies for now, but it sounds that this use case is real and cannot be
hidden under the carpet :-)

Willy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Sep 2017 14:17:51 +1000

On Wed, Sep 6, 2017 at 2:14 PM, Willy Tarreau <[email-masked]> wrote:
> transport layer but rejected by the application

It's worse than that, even the transport can't know whether the data
was delivered.  It's encrypted and the server can't decrypt it (or it
has to at least pretend that it can't decrypt it).

> I don't know what it

Rejection is a critical part of 0-RTT, yes.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Sep 2017 21:51:26 -0700

> OK, that's two arguing against continuing.
I am a bit concerned that the argument about Token Binding is specific
to HTTP. That would be an argument for placing the rejection behavior at
the app layer, instead of forcing it in the transport spec.
> that to saying that streams close.
Isn't that a violation of the general principle that streams shall only
be closed by the application?
> Also, you can't close stream 1.
That's HTTP specific, isn't it?

If I look at application-independent transport API, the simplest
solution is an "automatic restart" in which "all streams except stream 0
are put back in their original virgin state." This implies some kind of
check-pointing in the app, and that would be the price to pay for
attempting 0-RTT. I can hardly see any reason to do something special
for stream 1.

> https://github.com/quicwg/base-drafts/issues/762

We kind of agreed that the congestion controller behavior is "sender
only", and we only have to specify a New Reno equivalent. I would go
back to the initial condition.

-- 
Christian Huitema

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 6 Sep 2017 06:54:38 +0200

> has to at least pretend that it can't decrypt it).

I see. Maybe that could be considered equivalent to some out-of-band
data. Ie the sender would at least have to say "hey I sent you this
amount of early data, maybe you don't know what it is but please at
least ACK its receipt as something opaque".

Willy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Sep 2017 17:35:47 +1000

> the app layer, instead of forcing it in the transport spec.

Nick's argument was general, with a specific example from experience.
Any application protocol that uses early exporters will likely be
similarly affected.

> be closed by the application?

If the application has to treat the connection as a new one, the
transport isn't closing the streams, it's effectively closing the
connection and asking the application to try again (and promising that
that is safe to do).

> That's HTTP specific, isn't it?

Well, again that's a specific example of a general problem: the
transport can't close streams.

> attempting 0-RTT. I can hardly see any reason to do something special

Right, that's what Victor proposes.  It's also what TLS 1.3 recommends
in the analogous scenario.

> back to the initial condition.

What if you just sent a massive amount of data?  Do you really want to
send more without considering the potential impact that might have?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Sep 2017 19:52:04 +1000

> least ACK its receipt as something opaque".

That's the best solution I could think of as well.  It's not
particularly ideal, because the signal can't be authenticated and so
it would be subject to abuse and spoofing.  It's also possible that
some server deployments would reject 0-RTT because they can't
guarantee proper routing of those packets, which leads to a new
problem: they can't generate this pseudo-ACK at all and now you have
what appears to be a genuine loss scenario...

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Sep 2017 07:32:05 -0500

> send more without considering the potential impact that might have?

How much data can you have actually sent before receiving an early-data
reject, if you are complying with a congestion control scheme equivalent
to New Reno?

-Ben

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Sep 2017 07:06:47 -0700

On 9/6/2017 5:32 AM, Benjamin Kaduk wrote:

> How much data can you have actually sent before receiving an
> early-data reject, if you are complying with a congestion control
> scheme equivalent to New Reno?

If we assume that a clear text ACK cannot acknowledge encrypted packets,
0-RTT data packets cannot be acknowledged before the connection is
established. The sender can thus send at most an initial window.

>From a congestion control point of view, how should "reset after 0-RTT
reject" differ from starting a new connection?

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 7 Sep 2017 15:51:22 -0700

> reject" differ from starting a new connection?

I  wouldn't do anything different with the controller. The sender is not
going to receive acks for these packets, so it's best to do a clean slate
and start again with the initial window. The sender *could* do something
more complicated, like wait "a while" to let the network drain, but without
knowing what network bandwidth is,  the sender would still be in the dark
about how long to wait. Any wait time here will be wrong, just as wrong as
the initial window. So, I would reset the controller's state to initial
state.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Sep 2017 09:55:02 +1000

On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar <[email-masked]> wrote:
> The sender is not

I have copied the above text to the issue.  Is this a reasonable
position to take?  I think that it is.  (The something more
complicated might start at leaving the pacing timer running so that
you don't make things worse by that much at least.)

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 7 Sep 2017 17:19:19 -0700

I agree that it's a reasonable position to take (since I said it :-)) But
others should chime in.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Sep 2017 17:23:47 -0700

I tend to agree that this is the right answer.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Sep 2017 09:28:17 -0500

It seems like the right thing to do, to me.

-Ben

On 09/07/2017 07:19 PM, Jana Iyengar wrote:
> I agree that it's a reasonable position to take (since I said it :-))
> But others should chime in.
>
> On Thu, Sep 7, 2017 at 4:55 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Fri, Sep 8, 2017 at 8:51 AM, Jana Iyengar <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > The sender is not