Transport parameter that limits 0-RTT data

[martinthomson]

TLS has an extension on the NewSessionTicket that limits the amount of early data. This limits the number of plaintext octets (not including padding) that can be send in early data. This allows a server to constrain how much clients send in 0-RTT.

We could reuse and repurpose that extension for QUIC, but we would have to do so explicitly. Currently, we do not. Or, we could define a new transport parameter that explicitly limits the size of incoming 0-RTT data.

We could define this count in a number of ways:

1. Count the number of octets in each packet before packet protection is applied.
2. As 1, except after packet protection is applied.
3. Count everything except padding.
4. Count only STREAM payloads (i.e., use the same accounting as flow control).

I have a slight preference for option 4 for reasons what will become obvious in a parallel discussion (see #390).

[ianswett]

4 SGTM.

[RyanTheOptimist]

+1. STREAM payloads seems like the right choice.

…

On Tue, Mar 14, 2017 at 4:37 PM, ianswett ***@***.***> wrote: 4 SGTM. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#405 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASp6ygBoSssJLEZ_PIMqB6xtJ9435I6dks5rlyTTgaJpZM4MdRuK> .

[martinthomson]

This is covered by #512.