Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deprecate mplex #3866

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
+1 −26
Open

Deprecate mplex #3866

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 1 addition & 26 deletions specs/phase0/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,8 +63,6 @@ It consists of four main sections:
- [What are the advantages of using TCP/QUIC/Websockets?](#what-are-the-advantages-of-using-tcpquicwebsockets)
- [Why do we not just support a single transport?](#why-do-we-not-just-support-a-single-transport)
- [Why are we not using QUIC from the start?](#why-are-we-not-using-quic-from-the-start)
- [Multiplexing](#multiplexing-1)
- [Why are we using mplex/yamux?](#why-are-we-using-mplexyamux)
- [Protocol Negotiation](#protocol-negotiation-1)
- [When is multiselect 2.0 due and why do we plan to migrate to it?](#when-is-multiselect-20-due-and-why-do-we-plan-to-migrate-to-it)
- [What is the difference between connection-level and stream-level protocol negotiation?](#what-is-the-difference-between-connection-level-and-stream-level-protocol-negotiation)
Expand Down Expand Up @@ -157,15 +155,6 @@ During connection bootstrapping, libp2p dynamically negotiates a mutually suppor
This applies to transports that are natively incapable of multiplexing (e.g. TCP, WebSockets, WebRTC),
and is omitted for capable transports (e.g. QUIC).

Two multiplexers are commonplace in libp2p implementations:
[mplex](https://github.com/libp2p/specs/tree/master/mplex) and [yamux](https://github.com/libp2p/specs/blob/master/yamux/README.md).
Their protocol IDs are, respectively: `/mplex/6.7.0` and `/yamux/1.0.0`.

Clients MUST support [mplex](https://github.com/libp2p/specs/tree/master/mplex)
and MAY support [yamux](https://github.com/libp2p/specs/blob/master/yamux/README.md).
If both are supported by the client, yamux MUST take precedence during negotiation.
See the [Rationale](#design-decision-rationale) section below for tradeoffs.

## Consensus-layer network interaction domains

### Custom types
Expand Down Expand Up @@ -1121,20 +1110,6 @@ On the other hand, TLS 1.3 is the newest, simplified iteration of TLS.
Old, insecure, obsolete ciphers and algorithms have been removed, adopting Ed25519 as the sole ECDH key agreement function.
Handshakes are faster, 1-RTT data is supported, and session resumption is a reality, amongst other features.

### Multiplexing

#### Why are we using mplex/yamux?

[Yamux](https://github.com/hashicorp/yamux/blob/master/spec.md) is a multiplexer invented by Hashicorp that supports stream-level congestion control.
Implementations exist in a limited set of languages, and it’s not a trivial piece to develop.

Conscious of that, the libp2p community conceptualized [mplex](https://github.com/libp2p/specs/blob/master/mplex/README.md)
as a simple, minimal multiplexer for usage with libp2p.
It does not support stream-level congestion control and is subject to head-of-line blocking.

Overlay multiplexers are not necessary with QUIC since the protocol provides native multiplexing,
but they need to be layered atop TCP, WebSockets, and other transports that lack such support.
Comment on lines -1135 to -1136
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this paragraph about QUIC is valuable. I think we shouldn't lose it. Maybe should we change the topic to "Why are we using yamux?" instead and remove the mplex part?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better question might be "why don't we go straight to QUIC and skip yamux as a requirement"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better question might be "why don't we go straight to QUIC and skip yamux as a requirement"

Yeah, and the answer is that it's not easy to find a stable QUIC library for some programming languages and we decide to make QUIC optional instead, but preferable.

Copy link
Contributor

@arnetheduck arnetheduck Aug 8, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the rarity-of-implementation argument can be said of yamux too which is libp2p-only - https://blog.cloudflare.com/http3-usage-one-year-on saw 30% quic traffic share last year, meaning that any language that doesn't have a quic will have one soon.

ie in nim-libp2p, we have a yamux that hasn't been battle-tested really but it's kind of pointless spending time on it knowing that it's on its way out and entirely useless outside of a narrow libp2p window.

mplex otoh has been working for the consensus layer for years now so a few more months to get quic in place is not going to make any difference.


### Protocol Negotiation

#### When is multiselect 2.0 due and why do we plan to migrate to it?
Expand All @@ -1159,7 +1134,7 @@ All libp2p connections must be authenticated, encrypted, and multiplexed.
Connections using network transports unsupportive of native authentication/encryption and multiplexing (e.g. TCP) need to undergo protocol negotiation to agree on a mutually supported:

1. authentication/encryption mechanism (such as SecIO, TLS 1.3, Noise).
2. overlay multiplexer (such as mplex, Yamux, spdystream).
2. overlay multiplexer (such as Yamux, spdystream).

In this specification, we refer to these two as *connection-level negotiations*.
Transports supporting those features natively (such as QUIC) omit those negotiations.
Expand Down