roadmap: remove optimizations of the TCP-based handshake

[marten-seemann]

As an early result of the swarm metrics effort (#1910), we've discovered that >80% of the connections that a (full) node on the IPFS network establishes / accepts are QUIC connections. We can expect similar numbers for other libp2p networks that use go-libp2p (and that enabled the QUIC transport).

It therefore makes sense to focus our attention on cutting down roundtrips for QUIC users. This makes sense for multiple reasons:

1. At the risk of stating the obvious, improving the handshake latency for >80% of the connections is more impactful than improving the handshake latency for <20% of the connections.
2. Optimizing the TCP-based handshake by getting rid of the security protocol negotiation reduces the latency of a TCP handshake 4 to 3 RTTs (including Identify in the calculation here), that's 25%. Optimizing the QUIC handshake (by using 0.5-RTT data for Identify) allows us to bring down the latency from 2 to 1 RTT, a speedup of 50%.
3. Moving the security protocol is a complicated change, requiring changes to the libp2p specification (addressing: Specify security protocols in multiaddr specs#353), and requires both nodes to upgrade to the latest versions. Using 0.5-RTT data in QUIC on the other hand is a backwards-compatible change, as it doesn't require the client to upgrade. Thus, the performance impact will materialize much faster.

I suggest removing the TCP-based optimizations instead of just deprioritizing them, since given our current staffing situation, and the recent addition of the libp2p+HTTP work, we already have a lot on our plate.

[p-shahi]

I suggest removing the TCP-based optimizations instead of just deprioritizing them, since given our current staffing situation, and the recent addition of the libp2p+HTTP work, we already have a lot on our plate.

I agree with all these points, especially in the context of work for Q1 and Q2.

As an early result of the swarm metrics effort (#1910), we've discovered that >80% of the connections that a (full) node on the IPFS network establishes / accepts are QUIC connections.

Have these results been shared anywhere? I don't doubt the veracity of the claim but it links to an issue that is in progress without a PR.

80% of the connections that a (full) node on the IPFS network establishes
We can expect similar numbers for other libp2p networks that use go-libp2p (and that enabled the QUIC transport).

Since this is a profile of only the IPFS network, I worry we're being myopic about considering our customer needs. What do libp2p consumers that are rely purely on TCP (like Prysm) have to say about this? This may help us inform whether or not RTT optimization for TCP should be on the libp2p roadmap sooner than later. Also if there is a rough timeline for using QUIC in Eth/Prysm? (apologies if this has been discussed elsewhere.) cc: @nisdas

[marten-seemann]

As an early result of the swarm metrics effort (#1910), we've discovered that >80% of the connections that a (full) node on the IPFS network establishes / accepts are QUIC connections.

Have these results been shared anywhere? I don't doubt the veracity of the claim but it links to an issue that is in progress without a PR.

Not yet. The code is still work in progress, and my dev branch is only hooked up to my own Grafana instance at this point. I'm happy to share two screenshots:

@mxinden has shared some similar numbers using the brand-new rust-libp2p QUIC implementation.

[mxinden]

For what my input is worth, reasoning here makes sense to me 👍