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

go-libp2p v0.29 #2326

Closed
22 of 29 tasks
marten-seemann opened this issue Jun 3, 2023 · 7 comments
Closed
22 of 29 tasks

go-libp2p v0.29 #2326

marten-seemann opened this issue Jun 3, 2023 · 7 comments

Comments

@marten-seemann
Copy link
Contributor

marten-seemann commented Jun 3, 2023

🗺 What's left for release

Planned release date: 2023-07-14 (before the Kubo v0.22 rc cutoff: ipfs/kubo#9911)

Smart Dialing:

QUIC:

Misc:

Metrics:

🔦 Highlights

Smart Dialing

In our last release, we shipped Smart Dialing. To reiterate, it’s a clever way to reduce the number of spurious dials. Instead of dialing all addresses in parallel (which is what we did before v0.28), we now carefully rank the addresses and dial them one by one.

However, there were two areas where the logic we introduced could lead to suboptimal results:

  • There are some networks that block UDP. This means that we won’t be able to dial any QUIC or WebTransport connections at all. This is problematic since our smart dialing logic dials a QUIC address first before dialing a TCP address, which would lead to a regression for these users.
  • Similarly, not all ISPs support IPv6 yet. This is problematic as well, since we prefer IPv6 addresses over IPv4.

This is why smart dialing was disabled by default in v0.28.

For this release, we implemented a logic we call Black Hole Detection in this release. We now detect if UDP or IPv6 is completely blocked (blackholed) by observing the outcomes of dial attempts. When a black hole is detected, we skip QUIC / WebTransport and IPv6 addresses, respectively. This significantly reduces the number of unsuccessful dials for users in these environments. To monitor the status of black hole detection, we added two Grafana dashboards to our swarm dashboard, showing the percentage successful / failed dials on UDP and IPv6, and if that leads to our blackhole logic kicking in.

This now allows us to use RFC8305 Happy Eyballs for QUIC: When we dial a peer that has a QUIC IPv6 and IPv4 address, we dial the IPv6 address first, and only start dialing the IPv4 address if we haven’t heard back from the peer within 250ms. Only if we don’t hear back within another 250ms, we start dialing on TCP.

In a future release, we will enable a similar logic for TCP IPv6 and IPv4 addresses, however, this will require us to refactor our code a bit (see #2394 for details).

Preliminary measurements on the IPFS network show that:

  • In ~90% of the cases, we end up with a connection on the first address we dial.
  • Canceled connection attempts are reduced by more than 60% (compared to the v0.27 release).

Smart Dialing is now enabled by default. We don’t expect it to cause any performance regression, but if you find any problems, please open an issue. It can be disabled via a constructor option to libp2p.New:

libp2p.SwarmOpts(swarm.WithDialRanker(swarm.NoDelayDialRanker))

Metrics

Changelog

Contributors

Contributor Commits Lines ± Files Changed
Sukun 14 +1594/-711 48
Marco Munizaga 9 +1085/-541 48
Marten Seemann 14 +428/-205 44
Jorropo 4 +178/-51 8
Adrian Sutton 1 +190/-17 4
VM 2 +80/-79 49
Sahib Yar 1 +43/-4 5
Hlib Kanunnikov 2 +17/-14 5
libp2p-mgmt-read-write[bot] 1 +26/-0 1
GitHub 2 +6/-19 2
Prithvi Shahi 1 +3/-3 1
Bryan White 1 +2/-2 1

✅ Release Checklist

  • Stage 0 - Finishing Touches
    • Go through relevant libp2p repos looking for unreleased changes that should make it into the release. If you find any, cut releases.
    • Run go get -u ./... to see if there are any out-of-date deps that look important. If there are, bubble them. Try to avoid directly updating indirect deps in go-libp2p's go.mod when possible.
  • Stage 1 - Release
    • Publish the release through the GitHub UI, adding the release notes. Some users rely on this to receive notifications of new releases.
    • Announce the release on the discuss.libp2p.io.
  • Stage 2 - Update Upstream
  • Make required changes to the release process.
@p-shahi
Copy link
Member

p-shahi commented Jun 29, 2023

Per ipfs/kubo#9911 (comment) the Kubo 0.22 expected RC date is now (tentatively) 2023-07-20

@marten-seemann
Copy link
Contributor Author

I pushed the release date to end of next week (July 14th).

@MarcoPolo
Copy link
Collaborator

I'm likely going to defer #2369 until the next release. #2318 was already a big enough change and we are enabling smart dialing by default for the first time.

I'm almost hesitant to include #2318 in order to keep this release smaller. But I think if anything fails there it should fail fast. So it's probably okay.

@marten-seemann
Copy link
Contributor Author

Agreed. It’s ok to keep draft-29 around for another release. We will have to drop it in the next one though, since quic-go v0.37 is removing it.

@MarcoPolo
Copy link
Collaborator

v0.29.0 is released. Closing this issue.

@marten-seemann marten-seemann unpinned this issue Jul 19, 2023
@sukunrt
Copy link
Member

sukunrt commented Jul 20, 2023

I ran kubo v0.21.0 with v0.27.7 and v0.29.0.

  • We are making 30% fewer dials than before
  • Cancellations have reduced by 50%, from 60% of total dials to 30% of total dials
  • For dials which successfully establish a connection, average number of dials has reduced by 40% from 2.1 to 1.25 dials per successful connection.

The detailed numbers are here:

Successes Cancellations Total Cancelled Fraction
v0.27.7 908 1358 2266 0.60
v0.29.0 1083 456 1539 0.30
reduction 66% 32% 51%

@sukunrt
Copy link
Member

sukunrt commented Jul 20, 2023

We should link to the above numbers from the release notes. We should at least make it clear that cancellations are down from 60% of all dials to 30%.

cc @marten-seemann @BigLep

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@MarcoPolo @marten-seemann @sukunrt @p-shahi and others