feat(quic): promote to stable release

[mxinden]

Description

• Cut a stable release of libp2p-quic.
• Export libp2p-quic as libp2p::quic.
• Update examples to use libp2p-quic through libp2p.

Notes & open questions

With no bugs thus far reported for libp2p-quic v0.9.2-alpha and the two bug fixes #4165 #4304 I suggest we cut a stable release of libp2p-quic. Note that the bug fixes already existed in the previous quinn-proto implementation.

Objections by anyone?

//CC @jxs for sigp/lighthouse#4577

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

I am for it!

[dariusc93]

Im for it. I dont see this as a blocker (and I may make an issue about it very soon once i look more into it and get more data, metrics, etc) I think the only thing that might be worth looking into would be the increase memory usage. I dont have specific data in front of me at this moment that points to where its coming from (will have to rerun everything again since quic had change and previous data wouldnt really be relevant) but i have noticed that for the same number of connections with quic enabled have seen more memory usage compared to just using tcp. Eg Bootstrapping and having 1000 connections with just tcp have on avg ~100mb of memory usage. With quic enabled (including draft_29, havent tested it with just v1 yet) usually sees about ~450mb to ~600mb of usage. Dont really see this being a blocker though but just something worth mentioning in case others might see this as a reason to keep it as alpha.

[mxinden]

QUIC generally uses more memory than TCP because, while TCP allocates significant memory in the kernel, QUIC, being a user-space protocol, requires additional user-space memory allocations for its operation. Would that explain what you are seeing @dariusc93?

[dariusc93]

QUIC generally uses more memory than TCP because, while TCP allocates significant memory in the kernel, QUIC, being a user-space protocol, requires additional user-space memory allocations for its operation. Would that explain what you are seeing @dariusc93?

Hey @mxinden, thanks for the response. I am aware about quic using more memory than tcp, however when comparing to say go-libp2p, its more memory than usual (based on test prior to the recent change to quic, since I mentioned the memory usage in the original quic pr). Quickly looking at what is going on in the background, it looks like some of it may stems from allocations to hashmap within quinn-proto, but may have to look closer when i get a bit of time, but this weekend ill compare go-libp2p memory usage to the number of active connections to see how it might compare to rust-libp2p.

EDIT: Just to add in go-libp2p it uses between 200mb to 250mb on 1000 of active connections with quic connections, though I would probably need to do a check on whats being prioritized.

[mxinden]

but this weekend ill compare go-libp2p memory usage to the number of active connections to see how it might compare to rust-libp2p.

Much appreciated. Thank you @dariusc93. I have found heaptrack useful in the past.

EDIT: Just to add in go-libp2p it uses between 200mb to 250mb on 1000 of active connections with quic connections, though I would probably need to do a check on whats being prioritized.

How does that compare to Rust in the same scenario?

Adding another data point. The rust-libp2p based IPFS bootstrap node uses 14.37 GB for >35k in- and outbound connections. Though arguably, it handles little to no load per connection, only answering Kademlia requests.