Skip to content
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

Closed
Tracked by #174 ...
BigLep opened this issue Dec 13, 2022 · 8 comments · Fixed by #10132
Closed
Tracked by #174 ...

Remove default /quic (draft 29) support #9496

BigLep opened this issue Dec 13, 2022 · 8 comments · Fixed by #10132
Assignees
Labels
P2 Medium: Good to have, but can wait until someone steps up

Comments

@BigLep
Copy link
Contributor

BigLep commented Dec 13, 2022

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 .

@BigLep BigLep added the P3 Low: Not priority right now label Dec 13, 2022
@marten-seemann
Copy link
Member

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

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

@marten-seemann
Copy link
Member

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
Copy link
Contributor Author

BigLep commented Jun 14, 2023

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
Copy link
Member

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
Copy link
Member

lidel commented Jun 14, 2023

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
Copy link
Member

@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
Copy link
Member

lidel commented Jun 15, 2023

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

@lidel lidel added P2 Medium: Good to have, but can wait until someone steps up and removed P3 Low: Not priority right now labels Jul 4, 2023
@lidel lidel changed the title Remove default QUIC draft 29 support Remove default /quic (draft 29) support Jul 4, 2023
@BigLep BigLep mentioned this issue Aug 3, 2023
@BigLep BigLep assigned Jorropo and unassigned hacdias Sep 14, 2023
@BigLep
Copy link
Contributor Author

BigLep commented Sep 14, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Medium: Good to have, but can wait until someone steps up
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants