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

swarm: introduce address tiers to prioritize dials #1605

Closed
Tracked by #2326
marten-seemann opened this issue Jun 20, 2022 · 3 comments
Closed
Tracked by #2326

swarm: introduce address tiers to prioritize dials #1605

marten-seemann opened this issue Jun 20, 2022 · 3 comments
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature

Comments

@marten-seemann
Copy link
Contributor

Not all addresses are created equal, and we should be smarter when dialing:

  • We should prefer IPv6 over IPv4, implementing an Happy-Eyeballs-like mechanism as described in RFC 8305.
  • When given an IP multiaddr and a DNS multiaddr to dial (for any given transport), we should start dialing the IP address immediately, and start DNS resolution concurrently.
  • We should prefer QUIC over TCP. QUIC handshakes are fast (1 RTT), so giving QUIC a head start of a few hundred ms will allow us to not start the TCP handshake in the vast majority of cases.
  • We need to be able to learn from failed dials. Sometimes IPv6 is blackholed, or UDP. This blackholing will apply to address categories (it might work on the local network, but fail on the public internet), so the algorithm needs to be able to classify addresses.

Things to consider: it might be worth considering changing our transport interface, such that Dial is async and can be called with multiple addresses.

@marten-seemann marten-seemann added kind/enhancement A net-new feature or improvement to an existing feature exp/expert Having worked on the specific codebase is important effort/days Estimated to take multiple days, but less than a week labels Jul 2, 2022
@marten-seemann
Copy link
Contributor Author

marten-seemann commented Jun 7, 2023

Left to do to complete this effort:

  • smart dialing is implemented
  • detect UDP blackholes, and disable QUIC if detected
  • detect IPv6 blackholes, and disable IPv6 if detected, otherwise prioritize dials on IPv6 (RFC 8305)
  • metrics for blackhole detection
  • enable smart dialing by default

@marten-seemann marten-seemann mentioned this issue Jun 7, 2023
29 tasks
@sukunrt
Copy link
Member

sukunrt commented Jul 10, 2023

@marten-seemann we don't need to explicitly disable QUIC or IPv6, right? If they're black holed we will not dial those addresses and we won't establish any incoming connections either.

@marten-seemann
Copy link
Contributor Author

Closing this issue, since @sukunrt has successfully chewed through all of the above points. We still need to publish a blog post. I created libp2p/blog#92 to track that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants