-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove default /quic
(draft 29) support
#9496
Comments
Adding more context: libp2p/go-libp2p#1841. go-libp2p is planning to drop draft-29 support in ~6 months. |
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 NetworkIn 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-v1Nodes 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 nodesThis 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? |
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 |
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. |
cleaning this up sgtm, only caveat here is that removal of |
@lidel What would the new migration do? Would it be sufficient to rewrite every |
Yes, this feels like the safest thing we can do. |
/quic
(draft 29) support
@Jorropo : I assigned this to you as I understand this is being handled in ipfs/fs-repo-migrations#174 |
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 .
The text was updated successfully, but these errors were encountered: