Add support for QUIC

[p-shahi]

• Depends on QUIC support in node.js
  • https://github.com/nodejs/node/pull/38233
  • https://github.com/nodejs/node/pull/47289
  • https://github.com/nodejs/node/pull/44325
  • https://github.com/nodejs/node/pull/47927
  • https://github.com/nodejs/node/pull/48244
  • https://github.com/nodejs/node/pull/53256
  • https://github.com/nodejs/node/pull/52628
• Hole punching is more reliable with UDP (therefore QUIC) than TCP.

[nikelborm]

Hi, @p-shahi!

notion link for more reliable with UDP (therefore QUIC) is inaccessible

Could you please update it?

[SgtPooki]

JS colo 2024 rough discussion

• Cayman is doing this work and a part of this colo..

• all i'm doing for this is QUIC transport

• nodejs quic PRs are all focused on Webtransport as the exposed interface, which means js-libp2p can't really benefit from it for the QUIC transport. So we need this work completed.

• pinged Prithvi on slack to update notion link

Work for this is being done at https://github.com/ChainSafe/js-libp2p-quic

Update:

• rough functionality is there.
• the only annoying thing is dealing with stream read/writes.
• seemingly a bug in napi-rs?? instead of doing things an easy way, harder ways of doing them, working around this. Point of friction
  • need to create smaller reproducible example for "potential bug"
• more testing is needed
• it's passing transport compliance tests
• CI for releasing/publishing with napi-rs might need finagling.

What's next?

• more tests
• implementing into libp2p benchmarks? examples? playing around with it more?
• polishing, adding docs.
• add release CI to automatically publish
• Start webtransport listener?

[p-shahi]

@nikelborm The latest link for the hole punching measurement is here: https://github.com/probe-lab/network-measurements/blob/main/results/rfm15-nat-hole-punching.md#final-report-nat-hole-punching-measurement-campaign

and the final report actually shows: "In this NAT hole punching measurement campaign, we found that the success rate of hole punching is approximately 70%. Moreover, we discovered that the success of hole punching does not depend on the round trip time, and QUIC/UDP is not more likely to succeed than TCP" https://github.com/probe-lab/network-measurements/blob/main/results/rfm15-nat-hole-punching.md#conclusion-1

[2color]

Thanks for sharing @p-shahi! That's very helpful

I guess the insight regarding why is from this section

While the hole punch success rates for TCP and QUIC are roughly the same, we see a completely different picture when both clients are allowed to use both transports for hole punching. In that case, we end up with a QUIC connection in almost 81% of the cases. We can explain this with generally faster connection establishment of QUIC connections. libp2p tries to hole punch using both transports at the same time, so both connection attempts race against each other. As soon as one connection succeeds, libp2p closes the remaining in-flight ones.