From 1379c5ccb7dfd13fb3ee385a30781e2c289e4e43 Mon Sep 17 00:00:00 2001 From: Marten Seemann Date: Wed, 28 Sep 2022 13:52:23 -0700 Subject: [PATCH 1/2] roadmap: rewrite the section about efficient handshakes --- ROADMAP.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index e3ba9f90a..e526780ff 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -322,21 +322,19 @@ be achieved with the [WebTransport](#✈️-webtransport) protocol. **High priority for: IPFS** **What?** Establishing a connection and performing the initial handshake -should be as cheap and fast as possible. Supporting things like -*selective* stream opening, *preemption*, *speculative* negotiation, -*upfront* negotiation, protocol table *pinning*, etc. may enable us to -achieve lower latencies when establishing connections, and even the -0-RTT holy grail in some cases. These features are being discussed in -the *Protocol Select* protocol design. - -**Why?** Multistream 1.0 is chatty and naïve. Streams are essential to -libp2p, and negotiating them is currently inefficient in a number of -scenarios. Also, bootstrapping a multiplexed connection is currently -guesswork (we test protocols one by one, incurring in significant -ping-pong). +should be as cheap and fast as possible. On TCP, The current libp2p +handshakes spends one round-trip negotiating the security protocol, and +another roundtrip negotiating the stream multiplexer. +By using advanced features of the handshake protocol, we might even be +able to reach the holy grail of a 0-RTT handshake in some cases. + +**Why?** Applications rely on quick connection establishment. libp2p +shouldn't make them wait for any longer than absolutely necessary. **Links:** +- [security protocol in multiaddr](https://github.com/libp2p/specs/pull/353) +- [muxer selection in security handshake](https://github.com/libp2p/specs/pull/446) - [Protocol Select specification](https://github.com/libp2p/specs/pull/349) ### 🛣️ Peer Routing Records From 5c2f4c01e2d9d2e4c3d71de120fc6605f88f32b5 Mon Sep 17 00:00:00 2001 From: Marten Seemann Date: Mon, 3 Oct 2022 22:37:49 -0700 Subject: [PATCH 2/2] fix typos Co-authored-by: Max Inden Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com> --- ROADMAP.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index e526780ff..519ba17ed 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -322,9 +322,9 @@ be achieved with the [WebTransport](#✈️-webtransport) protocol. **High priority for: IPFS** **What?** Establishing a connection and performing the initial handshake -should be as cheap and fast as possible. On TCP, The current libp2p -handshakes spends one round-trip negotiating the security protocol, and -another roundtrip negotiating the stream multiplexer. +should be as cheap and fast as possible. On TCP, the current libp2p +handshake spends one round-trip negotiating the security protocol, and +another round-trip negotiating the stream multiplexer. By using advanced features of the handshake protocol, we might even be able to reach the holy grail of a 0-RTT handshake in some cases. @@ -333,8 +333,8 @@ shouldn't make them wait for any longer than absolutely necessary. **Links:** -- [security protocol in multiaddr](https://github.com/libp2p/specs/pull/353) -- [muxer selection in security handshake](https://github.com/libp2p/specs/pull/446) +- [Security protocol in multiaddr](https://github.com/libp2p/specs/pull/353) +- [Muxer selection in security handshake](https://github.com/libp2p/specs/pull/446) - [Protocol Select specification](https://github.com/libp2p/specs/pull/349) ### 🛣️ Peer Routing Records