Change:
This is without ticket re-use text. This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths. Did I get this right? Does this make sense? Should we put this in the document directly?
NAME NAME do you think we should include the table in the PR's description in the text? I think its contents are implied from the text, so adding more text is just being verbose. But I could be persuaded otherwise.
I think that it might be confusing. For instance, I see no reason that a client wouldn't have a fixed configuration. A client that never races resumptions could send N and 1 always.
Can you please provide text?
NAME I can't really provide text as I'm unclear on what the field is trying to even describe.

Discussion:
As per RFC5077, and as described in RFC8446, TLS servers vend clients an arbitrary number of session tickets at their own discretion in <del> NewSessionTicket messages.  There are two limitations with this design.  First, servers choose some (often hard-coded) number of tickets vended per connection.  Second, clients do not have a way of expressing their desired number of tickets, which can impact future connection establishment.  For example, clients can open multiple TLS connections to the same server for HTTP, or race TLS connections across different network interfaces.  The latter is especially useful in transport systems that implement Happy Eyeballs RFC8305.  Since clients control connection concurrency and resumption, a standard mechanism for requesting more than one ticket is desirable. </del> <ins> NewSessionTicket messages.  There are at least three limitations with this design. First, servers vend some (often hard-coded) number of tickets per connection.  Some server implementations return a different default number of tickets for session resumption than for the initial full handshake that created the session.  No static choice, whether fixed, or resumption-dependent is ideal for all situations. Second, clients do not have a way of expressing their desired number of tickets, which can impact future connection establishment.  For example, clients can open multiple TLS connections to the same server for HTTP, or race TLS connections across different network interfaces.  The latter is especially useful in transport systems that implement Happy Eyeballs RFC8305.  Since clients control connection concurrency and resumption, a standard mechanism for requesting more than one ticket is desirable. Third, all tickets in the client's possession ultimately derive from some initial full handshake.  Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time.  Consequently, a server may periodically force a full handshake even when the client presents a valid ticket.  When that happens, it is possible that any other tickets derived from the same original session are equally invalid. A client avoids a full handshake on subsequent connections if it replaces all stored tickets with fresh ones obtained from the just performed full handshake.  The number of tickets the server should vend for a full handshake may therefore need to be larger than the number for routine resumption. </ins> This document specifies a new TLS extension - "ticket_request" - that can be used by clients to express their desired number of session

for performing connection racing.  The Transport Services Architecture implementation from TAPS also describes how connections can race across interfaces and address families.  In <del> cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket invalidation by racing. </del> <ins> such cases, clients may use more than one ticket while racing connection attempts in order to establish one successful connection.  Having multiple tickets equips clients with enough tickets to initiate connection racing while avoiding ticket re-use and ensuring that their cache of tickets does not empty during such races.  Moreover, as some servers may implement single-use tickets, distinct tickets prevent premature ticket invalidation by racing. </ins> Connection priming: In some systems, connections can be primed or bootstrapped by a centralized service or daemon for faster

3. <del> Clients can indicate to servers their desired number of tickets for a single connection via the following "ticket_request" extension: </del> <ins> As discussed in introduction, clients may want different numbers of tickets for fresh or resumed handshakes.  Clients may indicate to servers their desired number of tickets for a single connection, in the case of a full handshake or resumption, via the following "ticket_request" extension: </ins> Clients MAY send this extension in ClientHello.  It contains the following structure: <del> The number of tickets desired by the client. Clients can use TicketRequestContents.count to indicate the number of tickets they would prefer to receive.  Servers SHOULD NOT send more tickets than TicketRequestContents.count, as clients will most likely discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. </del> <ins> The number of tickets desired by the client when the server chooses to negotiate a fresh session (full handshake). The number of tickets desired by the client when the server is willing to resume using the presented ticket. A client starting a fresh connection SHOULD set new_session_count to the desired number of session tickets and resumption_count to 0. Once a client's ticket cache is primed, a resumption_count of 1 is a good choice that allows the server to replace each ticket with a fresh ticket, without over-provisioning the client with excess tickets.  However, clients which race multiple connections and place a separate ticket in each will ultimately end up with just the tickets from a single resumed session.  In that case, clients can send a resumption_count equal to the number of sessions they are attempting in parallel.  (Clients which send a resumption_count less than the number of parallel connection attempts might end up with zero tickets.) When a client presenting a previously obtained ticket finds that the server nevertheless negotiates a fresh session, the client SHOULD assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption.  This includes tickets obtained during the initial full handshake and all tickets subsequently obtained as part of subsequent resumptions. Requesting more than one ticket in cases when servers select a full handshake helps keep the session cache primed. Servers SHOULD NOT send more tickets than requested for the handshake type selected by the server (resumption or full handshake). Moreover, servers SHOULD place a limit on the number of tickets they are willing to send, whether for full handshakes or resumptions, to save resources.  Therefore, the number of NewSessionTicket messages sent will typically be the minimum of the server's self-imposed limit and the number requested.  Servers MAY send additional tickets, up to the same limit, if the tickets that are originally sent are somehow invalidated. A server which supports and uses a client "ticket_request" extension MUST also send the "ticket_request" extension in the EncryptedExtensions message.  It contains the following structure: The number of tickets the server expects to send in this connection. </ins> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection

If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second ClientHello message.  Moreover, if this extension is present, a <del> client MUST NOT change the value of TicketRequestContents.count in the second ClientHello message. </del> <ins> client MUST NOT change the value of ClientTicketRequest in the second ClientHello message. </ins> 4.

The authors would like to thank David Benjamin, Eric Rescorla, Nick Sullivan, Martin Thomson, Hubert Kario, and other members of the TLS Working Group for discussions on earlier versions of this draft. <ins> Viktor Dukhovni contributed text allowing clients to send multiple counts in a ticket request. </ins>