Subject: [quicwg/base-drafts] Removing Transport Parameters from new_session_ticket (#1015)

From: Patrick McManus <[email-masked]>
Date: Wed, 13 Dec 2017 20:41:24 +0000 (UTC)

transport 7.4.2 says that if a new_session_ticket contains the transport parameters extension those parameters should be used as overrides when making future 0-rtt connections with the ticket. 

This is a little hairy to implement and seems to add a bunch of un-necessary complexity and confusion about which transport parameters to expect. The latter is especially concerning because a mixup there results in hard errors.

The motivation, afaict, is to allow smaller defaults for things that are flow controlled on 0rtt vs 1rtt. Presumably the 0-rtt connection would issue a bunch of flow control credits shortly after 1rtt keys are established to bring those two connection styles up to parity with each other.

I propose that transport parameters are removed from NST and the server simply always behaves in this way (i.e. use conservative values in transport parameters and then issue flow control credits when 1RT keys are established. irrespective of whether or not a 0-rtt phase was ever used).

Given that a server that is not going to authenticate its client can send flow control credits at 0.5RTT these updates arrive in the same flight as the handshake in the 1rtt case - i.e. its effectively not adding any latency.. certainly not enough latency to exhaust those smaller defaults.

The TLS APIs here can create quite a bit of complexity... e.g. great care needs to be taken to correctly correlate transport parameters with the right context.. it is a solvable problem, but the complexity seems un-necessary.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Dec 2017 13:47:48 -0800

I've been convinced (by Patrick) that this is valuable.  I'd like to see if anyone objects, but I plan to open a PR to simplify the spec unless I hear otherwise.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-351535596

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Dec 2017 16:07:49 -0800

Isn't there an implicit penalty with that approach that all streams will start with a small flow control window forever?  You might want a larger window for the initial flight of each stream, and the server can't send back credit on a client-initiated stream until it has seen the client initiate it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-351566189

---

From: Patrick McManus <[email-masked]>
Date: Thu, 14 Dec 2017 03:13:18 +0000 (UTC)

its an interesting point .. but it seems "don't do that" might be reasonable advice given that you're not going to very successfully partition a small connection window over a really short period of time anyhow.

a less attractive option is "we can fix that with a frame because afterall the other ones are covered by frames" out there too I guess..

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-351596134

---

From: janaiyengar <[email-masked]>
Date: Thu, 14 Dec 2017 06:55:14 +0000 (UTC)

@MikeBishop : that's an interesting issue that hadn't occurred to me... how does this get covered in the current spec? I guess the server uses what's in the NST forever, which seems better than using a small default forever, but there's no way for a server to indicate to a client that it is willing to change its initial flow window for subsequent streams, is there?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-351624863

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Dec 2017 12:21:17 -0800

In the current spec, the server only accepts 0-RTT if it's going to negotiate the same or larger values:

> A server MAY accept 0-RTT and subsequently provide different values for transport parameters for use in the new connection. If 0-RTT data is accepted by the server, the server MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT set values for initial_max_data or initial_max_stream_data that are smaller than the remembered value of those parameters. Similarly, a server MUST NOT reduce the value of initial_max_stream_id_bidi or initial_max_stream_id_uni.

If the server provides small values for the 0-RTT flight and the client discovers after 1-RTT that it can be more aggressive now, great!  If the server wants to reduce values, then it can't accept 0-RTT with larger numbers.

@mcmanus, is the concern here that it's harder to fish the values out of the NST message than out of the handshake for some reason?  That seems like TLS library implementation feedback primarily.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-351825058

---

From: Christian Huitema <[email-masked]>
Date: Sat, 16 Dec 2017 22:07:18 -0800

I concur with Patrick's assessment that "This is a little hairy to implement". It requires exercising a part of the TLS libraries that is often under-documented an untested. 

I think we would be better off just adopting some conservative default, kind of like the same spirit as IW10 for TCP.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-352234608

---

From: Patrick McManus <[email-masked]>
Date: Tue, 19 Dec 2017 17:17:01 +0000 (UTC)

In addition to the complexity of the TLS library, the complexity of getting the "right value" for transport parameters is a concern. Especially as a disagreement can lead to deadlock.

In particular we have a hierarchy of "initial parameters", "parameters on the NST", and "parameters on the post 0rtt handshake". That's an awful lot of inheritance rules for what is really a small amount of value.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1015#issuecomment-352826032