[WIP] [RFC] Multistream-2.0

multistream-2.0/packet-oriented.md

@@ -0,0 +1,40 @@
+# Packet-oriented Multiselect 2.0
+
+This proposal defines the packet-oriented extension of multiselect 2.0.
+
+## Protocols
+
+The needs of packet-oriented libp2p differ from those of stream-oriented libp2p
+in the following ways:
+
+- The underlying transports are message based, thus the requirements of a
+ multiplexer are significantly diminished. Messages across different protocols
+ are natively interleaved over a connectionless socket, so a multiplexer need
+ only tag messages with their protocol. There are no ordering or transmission
+ guarantees in packet-oriented transports such as UDP.
+- Packet-oriented communication is inherently unidirectional. Since there is no
+ notion of a connection or handshake in the underlying transports,
+ packet-oriented protocols may simply speculatively send along packets to their
+ peers until they receive a message instructing them otherwise.
+
+As a result, since the underlying transports (e.g. UDP) delimit individual
+messages received by a socket, it stands that it would be reasonable to extend
+multiselect 2.0 for the packet-oriented case, adding or augmenting the following
+messages:
+
+- `multiselect/dynamic-inline`: Similar to `multiselect/dynamic`, but doesn't
+ depend on a previous `multiselect/advertise`. Message is of the format:
+
+ ```
+ <multistream/multicodec><multistream/dynamic-inline><length(varint)><name(string)><id(varint)><optional payload>
+ ```
+
+ In this case, a dynamic identifier is established alongside the protocol's
+ string name.
+- `multiselect/dynamic`: An extended version of `multiselect/dynamic` that
+ supports the optional addition of a payload. This will be used to send
+ messages on a protocol for which a dynamic ID has been established via an
+ `advertise` or `dynamic-inline` message.
+- `multiselect/na`: Reject a protocol, referring to its dynamic identifier. This
+ always is in reference to an identifier established by the remote peer.
+- A version of `multiselect/multicodec` with optional payload

multistream-2.0/retrospective.md

@@ -0,0 +1,41 @@
+# Multistream-Select 1.0.0 Retrospective
+
+This short document aims to motivate the need for a new stream negotiation
+protocol.
+
+There are 5 concrete issues with multistream select.
+
+multistream-select:
+
+1. requires at least one round trip to be sound.
+2. negotiates protocols in series instead of in parallel. 
+3. doesn't provide any way to determine which side (possibly both) initiated the
+ connection/negotiation.
+4. is bandwidth inefficient.
+5. punishes long, descriptive, protocol names. 
+
+We ignore 1 and just accept that the protocol has some soundness issues as
+actually *waiting* for a response for a protocol negotiation we know will almost
+certainly succeed would kill performance.
+
+As for 2, we make sure to remember protocols known to be spoken by the remote
+endpoint so we can try to negotiate a known-good protocol first. However, this
+is still inefficient.
+
+Issue 3 gets us in trouble with TCP simultaneous connect. Basically, we need a
+protocol where both sides can propose a set of protocols to speak and then
+deterministically select the *same* protocol. Ideally, we'd also *expose* the
+fact that both sides are initiating to the user.
+
+By 4, I mean that we repeatedly send long strings (the protocol names) back and
+forth. While long strings *are* more user friendly than, e.g., port numbers,
+they're, well, long. This can introduce bandwidth overheads over 30%.
+
+Issue 5 is a corollary of issue 4. Because we send these protocol names *every*
+time we negotiate, we don't, e.g., send longer, better protocol names like:
+
+* /ai/protocol/p2p/bitswap/1.0
+* /ipfs/QmId.../bitswap/1.0
+
+However, multistream-select was *explicitly designed* with this use-case in
+mind.