Re: [webrtc-extensions] Consider an API for non-delivered messages in SCTP datachannels (#50)

> It's an interesting idea. I have been considering the same for the purpose of monitoring some signaling messages that are sent unordered with partial reliability, where it's hard to create a good higher level protocol.

Just to give some background, why `SCTP_SEND_FAILED_EVENT` does exist. SCTP was originally designed for transporting signalling messages and they must be delivered in sequence and it is better to drop messages than to deliver them in the wrong sequence. To keep the number of lost user messages as small as possible, the SCTP stack had to give the user messages back to the application in case the SCTP association fails. Then the application would send these messages on a different association (most likely to a different peer in a cluster), but only the messages which have no been sent at all, since only for them the sequence of deliver can be guaranteed to be correct.

This adds complexity to the API and the implementation of the upper layer, so I would only recommend using it if the application requires it or at least has a benefit.

> 
> With the current events from rfc6458, I think it would be hard to make something easily. With a custom implementation, it wouldn't be hard to the SCTP implementation to provide message lifecycle events, if requested. A message that is sent on a socket would have a state diagram with states:
> 
> * Queued (in send buffer, not yet assigned a MID to, and no fragment put on the wire)
> * Partially sent (for multi-fragment messages where at least one fragment has been put on the write)
> * Fully sent (all fragments have been put on the wire, but not yet acknowledged)
> * Acked (received has sent a SACK including it. Here, if we assume all SACKs are non-renegable, this is straightforward)
> * Lost (Message expired with not all fragments ever put on the wire)
> * Probably lost (Message expired before acked, but with all fragments sent at least once, so received _may_ have received it)

You could add some more values to the `ssfe_flags` of `struct sctp_send_failed_event`. But I would suggest to keep things as simple as possible. So only add values your  application really needs.

> 
> All states are not applicable for all messages, and all states may not be interesting to inform the upper layer about, but it is possible.
> 
> In `dcsctp::SendOptions`, I thought about adding a new parameter, e.g. `uint64_t client_message_id`, which if non-zero, would trigger callbacks whenever the message changes states, and using `client_message_id` to identify the message.

Doesn't `snd_context` of the `struct sctp_sndinfo` gives you what you want?

> 
> I might prototype it, and see if there are pitfalls. Partial reliability is one, of course, but also stream resetting (which may throw away messages) and if an association detects that the peer has restarted (receives an INIT, and restarts the association), as that may trigger resending of messages and reset their states.

Why is stream resetting (as used by WebRTC) throwing away messages? Closing a data channel is a reliable operation.

Why does restarting of an association result in resending of messages? When an association restarts, all buffered messages are given back to the application. SCTP does not resend anything.

> 
> If you are only interested in knowledge if a message was successfully received, I do agree that doing that in a higher layer protocol would be the reasonable choice. The other states may be harder or even impossible to find out without information from the SCTP socket implementation.



-- 
GitHub Notification of comment by tuexen
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/50#issuecomment-865137648 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 21 June 2021 15:53:18 UTC