RFC-7: expose message internals to the transport in order to implement a simple congestion protocol

[hugoArregui]

As part of https://rfc.decentraland.org/rfc/RFC-7 the ACK process will be removed from the protocol. Although the current implementation has some problems I think it also provides a simple congestion mechanism. The suggestion of implementing an equivalent of the current ACK process using a bidirectional stream is a good one, but there is no way to implement a better congestion mechanism without incurring in overhead.

If some internals (I'm thinking about message_id in this case) becomes available to the transport layer (WsTransport for example), we could implement a simple congestion mechanism at transport level, without having to add this kind of information to our own app protocol.

[menduz]

I think we could get to some decoration in the response of the server signaling that the stream needs acks

function streamWithAck<T extends object>(arg: T) {
  arg[Symbol.for('rpc-requires-ack')] = true
  return arg
}


function getServerSideModule() {
  return {
    async * remoteMethodWithAcks() {
      return streamWithAck(generator())
    },
    async * remoteMethodWithoutAcks() {
      return generator()
    }
  }
}

[menduz]

I don't think that should be exposed to the user. You can count how many messages you received

[hugoArregui]

Not to the user, to the transport, so we can implement a transport with a different congestion control. For example, let's say a want to have n bytes in flight, I could track the message_id and size of every message, and then have an ack message with a list of received message ids.

[menduz]

how does your proposal looks like in user code and what problem does it solve?

[hugoArregui]

In user code doesn't change, but if we change the signature of the transport from send(payload) to send(metadata: {message_id}, payload) so a custom transport can handle the message in some other way (like requesting ack for the message in the last n bytes for example). The problem it solves is the one this RFC addresses, currently the ACK per message is too much for some scenarios. The no ACK seems a bit dangerous to me in some situations, so I'll like to have the possibility to implement my own congestion protocol if this two extremes are not what I need.

[menduz]

the solution is clear with that:

• if you want, you can still use the ACKs
• if that's too much, you can edit your own payloads and do congestion control in user code layer, not in transport layer. that is: add the messageId or any needed thing to the serialized message