idea: optimistic failure resets

[whyrusleeping]

I was thinking that nodes could optimistically select a protocol and then start immediately sending data. If the other side cannot handle the assumed protocol, they could respond with a special reset message containing some number of bytes of random data. They would then read data from the other side until they get those random bytes back, signalling that the other side received the reset and acknowledged it, then they could run a full interactive negotiation handshake.

This would allow us to optimistically save an RTT in most common cases (including the ability to remember preferred protocols and assume them in the future).

It seems like a bit of a crazy idea, but I think it could actually be super useful. Let me know what you think.

[dignifiedquire]

I like the idea. I am not sure though if the "special reset message with random bytes" could be problematic or not. An alternative which ties into this would be to add some sort of cancel or close message into the protocol, which always means, drop out of the current selection, that way you would have a unified handling of this with regular things where you could actually switch or gracefully close protocols.

1. Regular

• send protocol id
• receive protocol id
• send data
• send close message
• receive close ack

2. Optimistic - all good

• send protocol id
• send data
• send close message
• receive close ack

3. Optimistic - failed

• send protocol id
• send data
• receive close message
• send close ack
• negotiate available protocol

[whyrusleeping]

@dignifiedquire theres no way you can do a 'close' message though. After the negotiate there are no guarantees. Thats the reason for the random bytes in my proposal, that is the close message. 32 random bytes is impossible to accidentally encounter in the same way that we don't find any collisions in sha256.

[dignifiedquire]

Right, I guess that works then. Might still be useful to expand to have it available as close message in other states of the protocol

[Stebalien]

This is a really neat idea. One concern, however, is that something will see this data and decide to send it back before we send back the reset (i.e., some logging system somewhere...). One way to work around this would be to transform the nonce before returning it, e.g., by XORing it with something known constant.

A paranoid alternative would be to send a cancel cookie along with the protocol and make sure we never send it again until we've received the protocol message from the other side. If we receive a set of available protocols from the other side instead of our protocol, we send the cancel cookie, a chosen protocol, and continue. However, that's an extra 32 bytes we have to send (do we care? we can probably send less) and a random number we have to generate (probably not that much of an issue, this random number doesn't have to be secure). We can also omit the cancel cookie if we're sure the other side supports the protocol (if they don't, they'll reset the connection).