Draft: draft-ietf-quic-transport

Commentary: This addresses some questions about use of multiple tokens , as well as cleaning up the text adjacent in minor ways . 
 The spec does n't define what is a client is supposed to do when it receives multiple NEWTOKEN frames . There seem to be multiple reasonable ways to handle this situation : client could always use the oldest token first . This would allow the client to establish multiple connections at the same time . client could replace any old tokens when receiving a new token . This has the advantage that the most recently issued token will ( presumably ) have the longest life time . Furthermore , if the server encodes connection statistics ( RTT , cwnd , etc . ) into the ticket , using the newest ticket would provide it with the most recent data . From the Slack discussion , a better way might be a combination of these two : When establishing a new connection , use the most recently obtained token first . When establishing another connection to the same server ( before receiving a new NEWTOKEN ) , use an older token .  might then want to remember n tokens per endpoint , if they expect to establish n new connections simultaneously ( or a few more than n , depending on the network conditions , to account for failed connection establishments ) . 
 Your suggestion SGTM . 
 This is fine , and it merely reflects reality : older tokens are less likely to be useful . But there is no harm in attempting to use any token , provided that it has n't been used before . 
 Do we need text about that ? do you want me to prepare a PR ? 
 I think that an editorial PR would be great . This is advice that does n't change interoperability . 
 Some suggestions , but looks good .
Paragraph (version A):
A token SHOULD be constructed for the server to easily distinguish it
from tokens that are sent in Retry packets as they are carried in the
same field.
Paragraph (version B):
A token SHOULD be constructed in a way that allows the server to
distinguish it from tokens that are sent in Retry packets as they are
carried in the same field.
Paragraph (version A):
A client SHOULD NOT reuse a token in different connections.  Reusing
a token allows connections to be linked by entities on the network
path (see migration-linkability).  A client MUST NOT reuse a token if
it believes that its point of network attachment has changed since
the token was last used; that is, if there is a change in its local
IP address or network interface.  A client needs to start the
connection process over if it migrates prior to completing the
handshake.
Paragraph (version B):
A client SHOULD NOT reuse a token in different connections.  Reusing
a token allows connections to be linked by entities on the network
path; see migration-linkability.  A client MUST NOT reuse a token if
it believes that its point of network attachment has changed since
the token was last used; that is, if there is a change in its local
IP address or network interface.  A client needs to start the
connection process over if there is any change in its local address
prior to completing the handshake.
Paragraph (version B):
Clients might receive multiple tokens on a single connection.  Aside
from preventing linkability, any token can be used in any connection
attempt.  Servers can send additional tokens to either enable address
validation for multiple connection attempts or to replace older
tokens that might become invalid.  For a client, this ambiguity means
that sending the most recent unused token is most likely to be
effective.  Though saving and using older tokens has no negative
consequences, clients can regard older tokens as being less likely be
useful to the server for address validation.