Remove default /quic (draft 29) support

[BigLep]

Kubo 0.18 shipped a migration to have listeners for /quic (draft 29) and /quic-v1 (RFC 9000). At some point, draft 29 support won't be needed. This is the tracking issue for removing /quic (draft 29) by default.

This is currently not a priority. The 0.18 release claimed to do this at some point in 2023.

More context is in multiformats/multiaddr#145 .

[marten-seemann]

Adding more context: libp2p/go-libp2p#1841.

go-libp2p is planning to drop draft-29 support in ~6 months.

[marten-seemann]

About 6 months have passed, and I'd like to evaluate the feasibility of dropping draft-29 support in the next release. It turns out that supporting both version causes quite a lot of complexity and ways in which things can go wrong.

Situation of the IPFS Network

In the most recent ProbeLab report, we can see that most of the network has upgraded to v0.18.0 or higher. v0.18.0 was the first version that added quic-v1 support. In terms of older versions with signification deployments, there's v0.17.0 with 12.5% and v0.16.0 with 6.5%.

What are the consequences of dropping quic in favor of quic-v1

Nodes that don't support quic-v1 won't be able to establish QUIC (draft-29) connections to nodes that dropped draft-29 support. They can still connect, as long as there's another transport that both nodes support, most likely TCP. We will see this in the swarm metrics in a slight increase in the fraction of TCP connections, as long as the legacy nodes are still active in the network.

This seems like a fair tradeoff. Node operators who haven't updated their node for 6 months probably don't care too much about squeezing out the last bit of performance. And if they do, that's a good incentive to upgrade 🙃

Caveat: The Nebula Crawler only shows DHT nodes

This is not the full picture, there's also temporary and non-public nodes, which wouldn't be included in network crawls. We can get an estimate for their version distribution by looking at what Kubo versions are used to connect to our bootstrap nodes. I'm not aware that these numbers are available anywhere though.

Again, the only consequence for legacy nodes connecting to bootstrappers would be that they'd use TCP instead of QUIC draft-29. Paying a penalty of a couple of roundtrips if you haven't upgraded your node in 6 months doesn't sound like a dealbreaker.

@BigLep, I remember that a few months ago you shared a list of these version numbers. Would it be possible for you to obtain an updated list with more recent numbers?

[BigLep]

Thanks for bringing this up @marten-seemann. I agree with the principle that we shouldn't incur maintenance cost due to complexity when there is a viable alternative for users, they've had months to upgradem and there is fallback that will still work (TCP).

In terms of the numbers, we can look at the peer ids connecting to the PL-run DHT bootstrappers: https://protocollabs.grafana.net/d/Xq89yqoVk/peerids?from=now-7d&to=now&orgId=1 . I have taken dumps of that before to classify. I think @iand has been getting dumps of this data as well since it's ultimately what is feeding into "number of unique peers" at https://probelab.io/ipfsdht/#ipfs-servers-vs-clients-plot

[marten-seemann]

In terms of the numbers, we can look at the peer ids connecting to the PL-run DHT bootstrappers: https://protocollabs.grafana.net/d/Xq89yqoVk/peerids?from=now-7d&to=now&orgId=1 .

Thank you, this is exactly what I was looking for. I'm surprised to see go-ipfs v0.13.0 and v0.8.0 that high up on the list. I think it's fine to incur a small latency penalty on their boostrapping process (by forcing a TCP dial), for the reasons outlined above. @ipfs/kubo-maintainers, does anyone disagree with this course of action? We'd then drop draft-29 in the go-libp2p v0.29 release.

[lidel]

cleaning this up sgtm, only caveat here is that removal of /quic listeners from Kubo will require us writing and releasing a migration, which is bit of additional work.
on the upside, it will be similar to ipfs/fs-repo-migrations#162 (where we duplicated /quic as /quic-v1, so we can mostly copy-paste, including tests)

[marten-seemann]

@lidel What would the new migration do? Would it be sufficient to rewrite every /quic to /quic-v1, and then dedup the set of resulting addresses?

[lidel]

Yes, this feels like the safest thing we can do.

[BigLep]

@Jorropo : I assigned this to you as I understand this is being handled in ipfs/fs-repo-migrations#174
We need to include a changelog entry for this.