search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.58k stars 275 forks source link

relay/DCUtR: Add Direct Connection Upgrade through Relay protocol #173

Closed vyzo closed 3 years ago

vyzo commented 5 years ago

still early draft, but it's an important subject that needs to gain some momentum.

In this specification, we describe a synchronization protocol for direct connectivity with hole punching that eschews signaling servers and utilizes existing relay connections instead.

Status: Ready for review.

raulk commented 5 years ago

@vyzo

@albrow and the 0x guys pointed us to the Trickle ICE spec, which seems like a relevant background read for us. I do expect our specs to be influenced by ICE – as a real-life, successful technology for coordinating hole punching between any two peers.

We should aim to reference ICE WG material to back up our ideas and routines.

vyzo commented 5 years ago

@raulk there is a reference to the ICE RFC already.

raulk commented 5 years ago

@vyzo great, I missed that. What are the parallels between the algo we propose and the ICE procedure?

vyzo commented 5 years ago

What are the parallels between the algo we propose and the ICE procedure?

It's like ICE without a signalling server, and distributed STUN - we rely on public peers to tell us our observed addresses instead of using STUN servers. Also note that ICE mainly caters to UDP, while we very much care for TCP.

yusefnapora commented 5 years ago

I think the Trickle ICE spec @raulk linked to is an iteration on ICE that incrementally exchanges candidates instead of sending them all at once. Apparently this lets you start testing connectivity sooner

dryajov commented 4 years ago

related previous discussion - https://github.com/libp2p/specs/pull/64

mxinden commented 3 years ago

@vyzo I will update this pull request with the latest changes in the Golang and Rust implementation. I hope you don't mind.

vyzo commented 3 years ago

yeah go for it

On Wed, Aug 11, 2021, 20:38 Max Inden @.***> wrote:

@.**** commented on this pull request.

In relay/DCUtR.md https://github.com/libp2p/specs/pull/173#discussion_r687040843:

+network notifications: the new direct connection will emit a new +Connected notification, while closing the relay connection will +sever existing streams and emit Disconnected notification. + + +### Protobuf + +TBD + +## Implementation Considerations + +There are some difficulties regarding implementing the protocol, at least in go-libp2p: +- the swarm currently has no mechanism for direct dials in the presence of existing connections,

  • as required by the upgrade protocol. +- the swarm has no logic for prioritizing direct connections over relay connections +- the current multistream select protocol is an interactive protocol that requires a single

Addressed in dfc988c https://github.com/libp2p/specs/commit/dfc988c55fb49288e556c614ec334da75a2a3ac4 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/pull/173#discussion_r687040843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAI4SUE4PZAXNCQWNJSCQDT4KYQVANCNFSM4HQM3A6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

vyzo commented 3 years ago

We had much better experimental success rate, 90% for UDP/QUIC. Maybe NATs have gotten better behaved in the 10-15 years since the literature, or at least our sample had better behaved ones.

On Mon, Aug 23, 2021, 14:17 Max Inden @.***> wrote:

@.**** commented on this pull request.

In relay/DCUtR.md https://github.com/libp2p/specs/pull/173#discussion_r693881802:

  • Packets should be sent in random intervals between 10 and 200 ms to each
  • address.

Done via 6f558f1 https://github.com/libp2p/specs/commit/6f558f13aa4cbfe8458a3207764bd52e3f61a573 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/pull/173#discussion_r693881802, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAI4SQL56BDHB6WDFOSCWDT6IU6NANCNFSM4HQM3A6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

mxinden commented 3 years ago

Thanks @vyzo.

https://github.com/libp2p/specs/pull/173/commits/cab60cced57e04a2b162b1b571187abc7d94bffa removes the concrete (outdated) success rate statements. My reasoning for removing them is the following: The results of Project Flare Phase 1 were convincing enough that we consider Project Flare worth finishing. We can only measure the real success rates once the protocols are widely deployed. Instead of outdated numbers in this spec from early on, I am in favor of removing them, maybe bringing them back once we have more data.

mxinden commented 3 years ago

Thanks to the many people involved here! :pray: