Subject: [quicwg/base-drafts] Provide separate transport parameters for 0-RTT (#126)

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 19:07:51 -0800

TLS provides an extension that limits the amount of data that can be sent during 0-RTT.  This is an explicit configuration item, even though TCP flow control would naturally limit the amount of data a client can send to a server with 0-RTT.  The reason for this is that servers might have to hold some or all of the 0-RTT data.  That buffering might be part of replay mitigation, for example.  A server that supports 0-RTT can use that limit to ensure that it doesn't have to buffer more than it is willing to buffer.

In #122, I have chosen to carry over the values for initial flow control window and concurrent stream limit.  We might want to provide separate transport parameters for 0-RTT so that servers can apply lower limits.

-- 
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/126

---

From: janaiyengar <[email-masked]>
Date: Tue, 10 Jan 2017 16:25:13 -0800

We could provide default minimums that are used by clients that have no server values yet.

-- 
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/126#issuecomment-271741128

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jan 2017 23:57:29 -0800

Discussed in Tokyo; agreement in the room that parameters define defaults, and clients SHOULD cache parameters and MUST use default values if the client doesn't cache. The server always has the ability to kick unruly clients.

-- 
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/126#issuecomment-274733818