QUIC IPv4 and IPv6

[kixelated]

Hey guys, I'm trying to figure out how to implement happy eyeballs for QUIC.

One of the differences between QUIC and TCP/TLS is that the first flight has a CPU cost in the form of TLS secret generation. If you create two separate QUIC connections, one for IPv4 and one for IPv6, you will pay this cost twice unless the delay between connections is sufficiently large enough.

Alternatively, if the QUIC client sends a copy of the Initial packet over both IPv4 and IPv6, I believe you can avoid this duplicate work. The packets being transmitted over IPv4 and IPv6 would be the same. The server would finish the handshake using the earliest (or both?) socket family.

Does this make sense? Is there any guidance on if happy eyeballs should happen at the transport or application level for QUIC?

[mxinden]

Alternatively, if the QUIC client sends a copy of the Initial packet over both IPv4 and IPv6, I believe you can avoid this duplicate work. The packets being transmitted over IPv4 and IPv6 would be the same. The server would finish the handshake using the earliest (or both?) socket family.

For what my opinion is worth, I consider this an optimization not worth specifying in the document.

We (Mozilla) expect the majority of connections to succeed on the first attempt, and thus will not introduce such optimizations (for now).

Is there any guidance on if happy eyeballs should happen at the transport or application level for QUIC?

The draft is currently specified at both the transport level (TCP) and application level (here TLS), see e.g.:

draft-happy-eyeballs-v3/draft-ietf-happy-happyeyeballs-v3.md

Lines 560 to 571 in f9fae35

	Client connections that use TCP only (without TLS or another protocol
	on top, such as for unencrypted HTTP connections) will determine
	successful establishment based on completing the TCP handshake
	only. When TLS is used on top of of TCP (such as for encrypted HTTP
	connections), clients SHOULD wait for the TLS handshake to
	successfully complete before cancelling other connection
	attempts. This is particularly useful for networks in which a
	TCP-terminating proxy might be causing TCP handshakes to succeed
	quickly, even though end-to-end connectivity with the TLS-terminating
	server will fail. QUIC connections inherently include a secure
	handshake in their main handshakes, and thus usually only need to
	wait for a single handshake to complete.

[nidhijaju]

Yes, the draft indicates that racing between attempts should continue up through TLS and QUIC, but it can apply even to plaintext TCP connections as well.

I'd second @mxinden's point: the idea behind delaying between attempts is to make the vast majority of connections succeed on the first attempt.

I'm not sure if there are additional privacy considerations around repeating the exact same QUIC Client Initial to multiple endpoints, but it seems worth being careful in that area.