protocol-select/: Add Protocol Select specification

[mxinden]

This pull request adds the specification for the Protocol Select protocol.

Protocol Select is a protocol negotiation protocol. It is aimed at negotiating libp2p protocols on connections and streams. It replaces the Multistream Select protocol.

Status

Ready for review.

See also protocol/web3-dev-team#119.

[vyzo]

thank you for putting this together, it is looking quite good.

[lanzafame]

Minor typo

[Stebalien]

Hm. So, I gave this as one of the primary motivations for Protocol Select, but it's not actually specific to Protocol Select, in it's current incarnation.

That is, I could use the same trick of aliasing codec-based protocol names in multistream.

Let's think very carefully about our upgrade path here. I'm now less convinced it's something we can punt because, well, it's kind of the main reason we wanted this protocol in the first place.

[kpp]

Do we really need to close a connection? I would say in case of QUIC one can open another substream using Multistream Select.

[marten-seemann]

In theory that would work, but it might be quite involved implementation-wise.

[yusefnapora]

I like how simple this protocol is, and the spec explains things well. Found a couple little typos - otherwise this is looking really nice.

[thomaseizinger]

Thanks for pushing this forward. Excited to see optimizations such as "Early data".

[cheako]

Why not take this opportunity to make breaking changes not split the network? Supporting multi-versions is a simple solution, there must be others:

syntax = "proto2";
message ProtoSelect {
    uint32 version = 1;
    uint32 max_forbid_version = 2;
    message Protocol {
        oneof protocol {
            string name = 1;
        }
    }
    repeated Protocol protocols = 3;
}

max_forbid_version is set/updated to the oldest/highest offensive version that is hereby banned... because

1. a change so critical it warrants banning all clients older than
2. years, perhaps decades and it's just time

Allow the other end to reply with, sorry, I speak version X and continue accordingly.

[mxinden]

Hi @cheako, I am sorry for the late reply here.

Why not take this opportunity to make breaking changes not split the network? Supporting multi-versions is a simple solution, there must be others:

I am not quite sure I understand where you are going with this. Could you describe a small scenario where the current versioning scheme would not suffice but your proposal would?

max_forbid_version is set/updated to the oldest/highest offensive version that is hereby banned... because

In particular I am having a hard time understanding why the max_forbid_version needs to be exchanged explicitly.

1. a change so critical it warrants banning all clients older than

Say client A receives a ProtocolSelect message with a version pre-cricitical-change from B, it could then simply cut off the connection. I expect clients to start with their highest version available, thus there is no need for A to retry as B likely does not support a higher version.

Allow the other end to reply with, sorry, I speak version X and continue accordingly.

Note that this would conflict with Optimistic Protocol Negotiation where the remote might have already sent application data.

[cheako]

The point is to avoid disconnection because version. So... The lower version should be the one to give up and disconnect when it can't satisfy the required version.

ACID rules should already cover the case where a transaction needs to be rolled back, so it's not a problem that a higher version sends some data that needs to be disregarded.

[mxinden]

Again, would you mind describing a concrete example where the current versioning scheme would not suffice? I am still having a hard time understanding which problem you are trying to solve @cheako.

[cheako]

The notion of a sudden disconnect is not expressive enough and is just ambiguous. I don't think it's right to put a lot of effort into the case where a node would be banned. However, it can be done more than the, simple and to the point, max_forbid_version scheme. Another solution is to have a response along with a disconnect(you can try to pad the TCP RST with data) clients are written to understand. There are three things I can think of for such a reply:

1. That you're being banned, the packet type(obviously the newer node would be sending a legacy packet) expresses this.
2. The severity of the ban, like should the application close(as in you're a danger to society) after getting a few of these, or is it just this node that it's banned from.
3. Documentation, a web address for the user to get more information as to why.
   a. The new software may have updated guidance for where documentation lives.

[Menduist]

As mentioned here #353 (comment), we could add a "Optimistic Data" field, that contains data for the first offered protocol.

If the receiver choose the first protocol, he will process that data. Otherwise, the source will have to resend it after the negotiation with the negotiated protocol.

This allow us to generalize "optimistic negotiation", without the risk of closing the stream/connection if we were too optimistic

[mxinden]

👍 This came up in previous discussions as well.

I would like to keep the first iteration of the protocol as simple as possible. As far as I can tell, this can be added in a backwards compatible way later on. Let me know in case I am missing something.

[Menduist]

Sure, though two things to keep in mind:

The "Optimistic Protocol Negotiation" from the current spec should probably be removed, to avoid clashes in the future

And to add backward compatibility in the future, we'll need need to add a "early data processed" bool to the listener -> initiator response, otherwise the initiator has no way to know if the early data has been processed. Not too much of a deal, though (I think)

[mxinden]

And to add backward compatibility in the future, we'll need need to add a "early data processed" bool to the listener -> initiator response, otherwise the initiator has no way to know if the early data has been processed. Not too much of a deal, though (I think)

That would require the listener to only send a Protocol Select message once it received the initiators message, right? If so, that would prevent all early-data optimizations where the listener side is able to send first.

[Menduist]

Right, might be an issue.

In the case where the listener side is sending first, we would have to flip the roles (the listener is becoming initiator)
AFAICT, we always know who should be the "protocol select initiator", even though it may not be the same as the "secure initiator"

But maybe there is a case where we don't know?