The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes.

ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet.

When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet.

In order to get the ClientHello message below 700 bytes, we will definitely need to remove the server certificate chain from the ticket (localCerts). We could either allow the resumed session to return null from getLocalCerts, or use a different way to serialize the local certificates (KeyManager alias?), possibly with an option to restore the original behavior.

Looking at the structure of our session ticket (the JavaDoc for SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) constructor), there are a few more fields we could probably remove:
- peerSupportedSignAlgs - could equally be picked up from the current session
- localSupportedSignAlgs - could be needed to force reauthentication when client certificates are in use (see test sun/security/ssl/SSLSessionImpl/ResumeChecksServerStateless.java), but otherwise looks unnecessary
- preSharedKey is only needed by TLS1.3 and could be omitted for pre-TLS1.3
- pskIdentity appears to be unused on the server side
- masterSecret is only needed by pre-TLS1.3 and could be omitted for TLS1.3. Also, masterSecret algorithm is ignored and can be dropped.
- useExtendedMasterSecret is only needed by pre-TLS1.3
- identificationProtocol is not used on the server side
- serverNameIndication is probably useful to prevent resumption with a different SNI, but requestedServerNames could equally well be taken from the new ClientHello
- maximumPacketSize and negotiatedMaxFragSize could probably be taken from the new handshake
- status responses are always null on the server side
- peer host and peer port are usually null on the server side, and when they are not, they are copied from the SSLEngine
- localCerts type was probably a misunderstanding of rfc5077, it should have been peerCerts.type. It can be dropped.