describe how a client is supposed to handle multiple tokens

[marten-seemann]

The spec doesn't define what is a client is supposed to do when it receives multiple NEW_TOKEN frames.

There seem to be multiple reasonable ways to handle this situation:

1. A client could always use the oldest token first. This would allow the client to establish multiple connections at the same time.
2. A 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 NEW_TOKEN), use an older token. Client 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).

[ianswett]

Your suggestion SGTM.

[martinthomson]

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 hasn't been used before.

[marten-seemann]

Do we need text about that? @martinthomson, do you want me to prepare a PR?

[martinthomson]

I think that an editorial PR would be great. This is advice that doesn't change interoperability.