QUIC's roadmap to stable

[Stebalien]

QUIC is better than TCP+yamux, etc. in pretty much every way and we should try to make it the default ASAP, even if that means not waiting for the IETF to come out with the final spec.

Remaining questions/issues are:

• Protocol Versioning: Do we need to use a /quic-alpha protocol/multicodec or can we rely on QUIC protocol version negotiation to catch protocol version mismatches. That is, is there any way to create "custom" protocol versions.
• Ed25519 support (QUIC transport constructor fails with ed25519 keys go-libp2p-quic-transport#60)
• Share the same handshake algorithm with the TLS transport (reuse code from go-libp2p-tls go-libp2p-quic-transport#18).
• Reuseport for dialing (implement connection reuse go-libp2p-quic-transport#63), important for NATs with symmetric port mapping.
• Settle on stream closure discussion (feat: add CloseRead/CloseWrite on streams go-libp2p-core#10)

Am I missing something?

[raulk]

Protocol Versioning: Do we need to use a /quic-alpha protocol/multicodec or can we rely on QUIC protocol version negotiation to catch protocol version mismatches. That is, is there any way to create "custom" protocol versions.

@marten-seemann - does the QUIC WG make any guarantees in terms of backwards compatibility of drafts?

[raulk]

Am I missing something?

@Stebalien – We need to settle on the stream closure discussion. Added a point for that. Update: I chatted with @marten-seemann a few days ago, and clarified a misunderstanding he had about the current behaviour of Stream#Close(). We're close to consensus on that issue.

[marten-seemann]

Thanks for opening this issue @Stebalien. Unfortunately, it looks like the release of the RFC might take some more time, so I was about to suggest the same thing.

Protocol versioning is solved QUIC itself. Every new draft (which is published at least 3 times / year) bumps up the version number, so we won't even have to use custom version numbers here, we can just use the official draft version number. @raulk There's no backwards compatibility between draft versions (things are already complicated enough within one version), but an implementation may support multiple versions at the same time.

Ed25519 support and sharing the handshake with TLS is really the same issue, since the TLS handshake already has Ed25519 support. Implementing this will be messy, since on QUIC, we don't accept an underlying connection first, on which we then perform the handshake (and the tls.ClientHelloInfo doesn't come with a context). We can work around this by keeping some tracking data structure in go-libp2p-quic-transport. Won't be the nicest code, but we can get it working nevertheless. I'll start working on a PR when I'm back from the IETF meeting.

I'm not sure if we really need to block this on the connection reuse but if so, libp2p/go-libp2p-quic-transport#63 is a draft PR that I'd like to get some comments on before moving forward.

[Stebalien]

Awesome! (well, not the RFC delays but getting the protocol right trumps everything).

I'm not sure if we really need to block this on the connection reuse but if so, libp2p/go-libp2p-quic-transport#63 is a draft PR that I'd like to get some comments on before moving forward.

I'd like feature parity with TCP if we're going to make this the default.

[marten-seemann]

Settle on stream closure discussion (libp2p/go-libp2p-core#10)

I'm wondering if this should be separate from this issue. We already have a stream interface that works. Settling the stream closure discussion might or might not require us to change the wrapping of quic-go in go-libp2p-quic-transport, but that applies for the other stream multiplexers as well.

[marten-seemann]

QUIC has been a default transport for a while now.