Proposal: Add MPP for libp2p _Protocol Select_ protocol

[mxinden]

Adds a Minimal Project Proposal for Protocol Select, the successor
of the libp2p protocol negotiation protocol multistream-select 1.0.

---

Status

Ready for review.

[mxinden]

This minimal project proposal is ready for review. @BigLep could you help steering this in the right direction?

[BigLep]

Thanks for putting this together @mxinden and @marten-seemann.

Is there anyone else we should flag for this review? @marten-seemann : who have been historical folks that you would want to make sure is aware of this effort? I know we'll also tag them once we have the spec, but for visibility, it's good to flag now as well I believe.

[BigLep]

Does this really matter? Do we have a ballpark of how much bandwidth we can save?

[mxinden]

This is debatable and not relevant in all scenarios.

Let's put the bandwidth requirement of a plaintext protocol string in relation to the remaining bytes to be send with the example below:

Say we want to send a Kademlia FindNode request to a remote peer. In order to do that we would need to:

1. Negotiate the Kademlia protocol on a new stream
2. Send the FindNode message payload to the remote.

For (1) we will need to send /multistream/1.0.0 (18 bytes) and /ipfs/kad/1.0.0 (15 bytes). For (2) we would need to send the FindNode message with the peer ID of the node to be found (44 bytes).

With Protocol Select we would not have to send /multistream/1.0.0 (18 bytes). In addition, with the above proposed bandwidth optimization, instead of sending /ipfs/kad/1.0.0 (15 bytes), we might be able to reduce the protocol identifier to ~2 bytes.

All that said, Protocol Select will likely not tackle this in the first iteration / roll out version. It will only be designed in a way to enable this optimization in future versions.

[mxinden]

Thanks @BigLep for taking a look.

Is there anyone else we should flag for this review?

Tagging @vyzo and @Stebalien, though I am reasonably sure they are already aware of this concrete minimal project proposal.

@BigLep what are next steps here? Would this pull request be merged once accepted, or would we simply change the status of the pull request?

[mxinden]

This is debatable and not relevant in all scenarios.

Let's put the bandwidth requirement of a plaintext protocol string in relation to the remaining bytes to be send with the example below:

Say we want to send a Kademlia FindNode request to a remote peer. In order to do that we would need to:

1. Negotiate the Kademlia protocol on a new stream
2. Send the FindNode message payload to the remote.

For (1) we will need to send /multistream/1.0.0 (18 bytes) and /ipfs/kad/1.0.0 (15 bytes). For (2) we would need to send the FindNode message with the peer ID of the node to be found (44 bytes).

With Protocol Select we would not have to send /multistream/1.0.0 (18 bytes). In addition, with the above proposed bandwidth optimization, instead of sending /ipfs/kad/1.0.0 (15 bytes), we might be able to reduce the protocol identifier to ~2 bytes.

All that said, Protocol Select will likely not tackle this in the first iteration / roll out version. It will only be designed in a way to enable this optimization in future versions.

[marten-seemann]

I've added some reviewers, mostly people who were involved in the multistream 2.0 discussion. Would love to hear their feedback!

[BigLep]

@BigLep what are next steps here? Would this pull request be merged once accepted, or would we simply change the status of the pull request?

I'm going to move this to In Progress, given Stewards are working on this by putting together an official spec: libp2p/specs#349

If there are no concerns from others that we're working on specing this, I think reviewers can leave their comments in the spec itself.

[yusefnapora]

Big 👍 to this proposal 😄

I'll check out the draft spec and chime in if I have any opinions.