Change:
This improves both happy eyeballs and ticket reuse.
I am significantly skeptical re complexity. The server looks at one counter when resuming and the other when doing a full handshake. Where's the complexity? I am sorry to say that to me personally, the complexity objection sounds rather like reluctance to reconsider the design than a response on the merit.
I still don't think that the additional count is warranted. The rationale here is reasonable, and does provide a degree of justification for the change, but I would prefer not to take on the additional complexity.Thanks for making the updatesThanks for putting this down in writing! I think a separate counter is fine given the rationale, but I disagree with all text on re-use. I think that should happen elsewhere. So, requesting changes for now, though if the WG decides to address ticket re-use here then we will revisit!

Discussion:
requesting more than one ticket is desirable. Third, we should note that the various tickets in the client's <del> possession ultimately derive from an initial full handshake. </del> <ins> possession ultimately derive from some initial full handshake. </ins> Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time. <del> Consequently, a server may periodically perform a full handshake even </del> <ins> Consequently, a server may periodically force a full handshake even </ins> when the client presents a valid ticket for a session that is too <del> old.  When that happens, it is possible that all 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 values.  The number of tickets the server should vend for a full handshake may therefore need to be larger than the number for routine resumption. </del> <ins> old.  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

following structure: The number of tickets desired by the client when the server <del> chooses to negotiate a fresh session (full handshake), thereby implicitly invalidating all other tickets sharing the same initial session as the presented ticket.  This is also the ticket count requested when the client presented no initial ticket making a full handshake unavoidable. </del> <ins> chooses to negotiate a fresh session (full handshake).  This is also the ticket count requested when the client presented no initial ticket making a full handshake unavoidable. </ins> The number of tickets desired by the client when the server is <del> willing to resume the associated session. </del> <ins> willing to resume using the presented ticket. </ins> Clients can use the above structure to indicate the number of tickets they would prefer to receive when sessions are resumed or new

resumption_count commensurate with the number of parallel sessions would be used. <ins> Priming of the ticket cache need not happen all at once.  Clients that anticipate opening frequent connections to a given server can ask for 2 or 3 tickets on each full handshake, and attain the requisite steady-state cache size after a few initial full handshakes, without substantial risk of "overshoot" or need to accurately predict the connection concurrency. 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 not only the tickets obtained during the initial full handshake, but all tickets subsequently obtained as part of subsequent resumptions.  Requesting more than one ticket in case a full handshake is forced by the server helps to keep the session cache primed. </ins> On the other hand, with e.g. server-to-server traffic with fixed <del> source addresses and no connection racing, ticket reuse may be appropriate.  Clients that wish to reuse tickets when possible should send an extension with the resumption_count set to 0, and the </del> <ins> source addresses and no connection racing, ticket reuse may be an option (ticket reuse is NOT RECOMMENDED per Section C.4 of RFC8446, and is only appropriate when replay and privacy concerns do not apply).  Clients that wish to reuse tickets when possible should send an extension with the resumption_count set to 0, and the </ins> new_session_count set to the value desired for a full handshake (typically 1).

type selected by the server (resumption or full handshake) as clients will most likely discard any additional tickets. <del> When a resumption is performed, and the requested resumption_count is zero, the client is requesting ticket reuse.  If the presented ticket is valid for additional resumptions (only possible when the server supports reuse), it SHOULD return no tickets.  Otherwise, when either the server does not support reuse, or the ticket is expiring, and needs to be replaced (e.g. reissued under a fresh session-ticket encryption key) the server SHOULD return one ticket. </del> <ins> When the client presents a ticket for resumption, but the requested resumption_count is zero and the new_session_count is non-zero, the client is requesting ticket reuse (despite section C.4 of RFC8446). If the presented ticket is valid for additional resumptions (only possible when the server supports reuse), it SHOULD return no tickets.  Otherwise, when either the server does not support reuse, or the ticket is expiring, and needs to be replaced (e.g. reissued under a fresh session-ticket encryption key) the server SHOULD return one ticket. </ins> Servers SHOULD additionally place a limit on the number of tickets <del> 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 the number requested. </del> <ins> 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. </ins> 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.new_session_count indicates the number of <del> tickets the server expects to send to the client. If the extension is echoed, the TicketRequestContents.resumption_count can be set to a non-zero value to indicate that the server supports ticket reuse, otherwise (i.e. zero) the server does not support ticket reuse.  Ticket reuse has privacy implications and should be used with care or not at all, see the security considerations section. </del> <ins> tickets the server expects to send to the client.  If the extension is echoed, the TicketRequestContents.resumption_count can be set to a non-zero value to indicate that the server supports ticket reuse, otherwise (i.e. zero) the server does not support ticket reuse. Ticket reuse has privacy implications and should be used with care or not at all, see the security considerations section and section C.4 of RFC8446. </ins> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection