On transport upgrades and the role of libp2p-core

[thomaseizinger]

With the introduction of QUIC and WebRTC, we are adding two transports to the codebase that offer native multiplexing. With TCP and other transports, we had upgrade a connection to a multiplexed one by putting yamux or mplex on top of an established connection. This upgrade mechanism doesn't really fit that well if a transport offers multiplexing capabilities out of the box.

Within our repository, the end consumer of libp2p-core - which hosts the abstractions of Transport, StreamMuxer and upgrades - is libp2p-swarm. A Swarm only works with a Transport that has been "upgraded" to support multiplexing because Swarm offers substreams as a communication abstraction to its users: NetworkBehaviours.

Both of these points indicate that the interface of libp2p-core is actually sub-optimal.

• Swarm does not need to know that Transport and StreamMuxer are different interfaces / technologies. The ideal interface for a Swarm is the combination of both.
• For technologies such as QUIC and WebRTC, we are introducing an unnecessary split between the actual Transport and the ability to open/manage substreams.

I'd like to open a discussion and gather ideas for a new interface exposed by libp2p-core. To avoid confusion with existing naming, I am going to name it MultiplexedTransport but really the name does not matter. The hierarchy would look something like this:

Most importantly, libp2p-swarm would only deal with the MultiplexedTransport interface. ComposedTransport would act as an adapter for combining technologies such as TCP and Yamux to fulfill the required interface.

I think this design would have a number of benefits:

• For technologies such as QUIC or WebRTC, the implementation might be simpler
• libp2p-core by itself could form a more useful abstraction for other libraries and act as general-purpose networking layer

Very curious to hear people's opinions on this idea!

[thomaseizinger]

An open question to this would be how the encryption & authentication layer fits into this. At the moment this is also modeled via upgrades but contrary to multiplexing, this isn't enforced on the Swarm level other than each new connection must yield a PeerId in addition to a StreamMuxer.

The fact that this is modeled with a tuple has always bugged me a bit and I think it is something that is quite hard to understand when one dives into the details of libp2p-core and libp2p-swarm.

If MultiplexedTransport would also enforce encryption & authentication, quite a few things would move from libp2p-swarm into libp2p-core which would make sense I think? libp2p-core would concern itself with transport technologies and libp2p-swarm would be the actor model on top of it with NetworkBehaviour at its core.

[mxinden]

What would such new abstraction in libp2p-core look like? Something along these lines where QUIC and WebRTC would implement MultiplexedTransport directly?

@@ -225,6 +225,37 @@ pub trait Transport {
     }
 }
 
+pub trait MultiplexedTransport {
+    type Error: Error;
+    type ListenerUpgrade: Future<Output = Result<(PeerId, StreamMuxerBox), Self::Error>>;
+    type Dial: Future<Output = Result<(PeerId, StreamMuxerBox), Self::Error>>;
+
+    fn listen_on(&mut self, addr: Multiaddr) -> Result<ListenerId, TransportError<Self::Error>>;
+
+    fn remove_listener(&mut self, id: ListenerId) -> bool;
+
+    fn dial(&mut self, addr: Multiaddr) -> Result<Self::Dial, TransportError<Self::Error>>;
+
+    fn dial_as_listener(
+        &mut self,
+        addr: Multiaddr,
+    ) -> Result<Self::Dial, TransportError<Self::Error>>;
+
+    fn poll(
+        self: Pin<&mut Self>,
+        cx: &mut Context<'_>,
+    ) -> Poll<TransportEvent<Self::ListenerUpgrade, Self::Error>>;
+
+    fn address_translation(&self, listen: &Multiaddr, observed: &Multiaddr) -> Option<Multiaddr>;
+}
+
+impl<T> MultiplexedTransport for T
+where
+    T: Transport<Output = (PeerId, StreamMuxerBox)>,
+{
+    // ...
+}
+

Swarm does not need to know that Transport and StreamMuxer are different interfaces / technologies. The ideal interface for a Swarm is the combination of both.

Agreed.

* For technologies such as QUIC and WebRTC, we are introducing an unnecessary split between the actual `Transport` and the ability to open/manage substreams.

What would be an example where we could simplify QUIC or WebRTC in case we had MultiplexedTransport?

The fact that this is modeled with a tuple has always bugged me a bit and I think it is something that is quite hard to understand when one dives into the details of libp2p-core and libp2p-swarm.

Agreed. To add to this, working with a tuple, instead of two separate types also makes referencing them in trait bounds difficult / impossible.

libp2p-core would concern itself with transport technologies and libp2p-swarm would be the actor model on top of it with NetworkBehaviour at its core.

Independent of the direction of this effort, the above line should make it into our docs somewhere. Potentially extending the definition here

rust-libp2p/src/tutorials/ping.rs

Lines 125 to 127 in d92cab8

	//! [`NetworkBehaviour`]. While the previously introduced trait [`Transport`]
	//! defines _how_ to send bytes on the network, a [`NetworkBehaviour`] defines
	//! _what_ bytes to send on the network.

[thomaseizinger]

Regarding what this would look like, I think a Connection abstraction that allows one to open substreams would already come a long way. Perhaps all we need is to have Transport yield a Connection struct or something that implements a Connection trait?

[mxinden]

And such a Connection trait could expose the PeerId via a method and thus we would get rid of the tuple.

[thomaseizinger]

I am wondering whether we should use the same Transport abstraction for things like noise and this. In other words, should Transport be abstract over the connection it yields like it is now or should we have a separate trait (MultiplexedTransport?) that is hard-wired to `Connection?

I am tending towards the latter because it is simpler to understand if the interfaces are more concrete and have less moving parts.

[thomaseizinger]

• For technologies such as QUIC and WebRTC, we are introducing an unnecessary split between the actual Transport and the ability to open/manage substreams.

What would be an example where we could simplify QUIC or WebRTC in case we had MultiplexedTransport?

Am I wrong that we wouldn't need the channels we currently have between Transport and StreamMuxer?