RTCSctpCapabilities maxMessageSize issues

[lgrahl]

I see two problems with the maxMessageSize attribute of RTCSctpCapabilities:

1. An unsigned short provides insufficient space. I'm not entirely sure what the maximum message size of SCTP effectively is, maybe @tuexen can add a statement to that. However, streaming APIs should be able to handle messages of arbitrary size (although the W3C API is not a streaming API, other implementations may provide one).
2. We should clarify that 0 indicates that the other peer can handle messages of any size. This is particularly important once SCTP ndata will be deployed.

For reference, here is the SDP section relevant for WebRTC.

[aboba]

In WebRTC 1.0, the maxMessageSize attribute is an unsigned long, so there is a potential compatibility issue:
https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#rtcsctptransport-interface

[lgrahl]

unsigned long means uint64_t right? That should be sufficient. :)

WebRTC 1.0 also does not clarify the 0 case. Maybe we should ping them about that as well.

[tuexen]

On 17 Dec 2016, at 17:11, Lennart Grahl ***@***.***> wrote: I see two problems with the maxMessageSize attribute of RTCSctpCapabilities: • An unsigned short provides insufficient space. I'm not entirely sure what the maximum message size of SCTP effectively is, maybe @tuexen can add a statement to that. However, streaming APIs should be able to handle messages of arbitrary size (although the W3C API is not a streaming API, other implementations may provide one).

SCTP has no message size limit. The protocol can handle messages of arbitrary size. However, since buffers are finite, it uses partial delivery at the receiver side and an explicit EOR mode on the sender side, if you follow the SCTP socket API specified in https://tools.ietf.org/html/rfc6458. The JS APIs doesn't support this, so they need to buffer the complete messages. Therefore the limit is actually a limit enforced by the code running on top of the SCTP implementation. Best regards Michael

…

• We should clarify that 0 indicates that the other peer can handle messages of any size. This is particularly important once SCTP ndata will be deployed. For reference, here is the SDP section relevant for WebRTC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lgrahl]

Thanks Michael. Taking into account that implementations can set maxMessageSize to 0 to indicate support for messages of arbitrary size, having a 64 bit unsigned integer should be absolutely fine. Implementations that choose to limit message sizes will usually choose a much lower amount than 2^64 anyway (but it's good to have the full range from 1 to 2^64).

[aboba]

Proposed resolution: change to unsigned long

[lgrahl]

And maybe adding something like this to the description:

A value of 0 indicates that messages of arbitrary size can be handled.

[robin-raymond]

@lgrahl if EOR is not supported, maxMessageSize is limited to the max SCTP packet size and arbitrary sizes cannot be supported. Even if this limitation was fixed, message sizes are still not unlimited due to other constraints (e.g. memory). Even TCP has max message sizes, but it gets around this by sends of some of the buffer rather than all of the buffer, but we can't do that here because the buffers are all or nothing. Thus I prefer to have a max size without a "0" to a) not require an additional "if (0 == maxMessageSize)" checks and b) there's always realistically going to be a maxMessageSize. I'm okay with a large possible value though up to 2^64.

[lgrahl]

I do understand that this is a limitation of ORTC's design as we do not have a streaming API. Yes, I agree that 2^64 is more than enough, don't get me wrong. But 0 is definitely not a valid maxMessageSize as SCTP cannot handle empty messages, so it needs to be handled differently anyway, right? So, I don't understand your point that additional checks would be required.

0 would be a crystal clear indication for fragmentation/reassembly projects such as https://github.com/saltyrtc/chunked-dc-js that no chunking is needed at all. While 2^64 can be interpreted as unlimited, everything below that is a question mark: Is it large enough for my use case or do I need to turn on fragmentation/reassembly?

Furthermore, I probably should have mentioned earlier that draft-ietf-mmusic-sctp-sdp does handle the 0 case.

Edit: Sorry for all the editing.

[aboba]

@lgrahl @pthatcher @robin-raymond In looking at the usage of maxMessageSize within the start method and example code, some questions arise. As defined in WebRTC 1.0, maxMessageSize represents a limitation on the use of the send() method, for the application developer to take into account. However, in Example 22, maxMessageSize is exchanged in signaling and the start method is called with remoteCaps as an argument. Passing the remote maxMessageSize to the start method would seem to imply that the local implementation will do something with this information, but it isn't clear to me what this should be.

[aboba]

@lgrahl @pthatcher While draft-ietf-mmusic-sctp-sdp does handle 0 as unlimited, is this something that implementations support? Given that Binary Partial and String Partial are both deprecated within the SCTP parameters registry (see http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25), I don't see how this is expected to work.

[lgrahl]

@aboba I'm not sure if I understand your question correctly, but basically this value needs to be stored and checked in send calls. This also means that RTCDataChannel.send is not available before the SCTP transport is in the connecting state. But this isn't a problem as the data channels wouldn't be open at that point.

Regarding your second question: Yes, implementations can support messages of arbitrary size by using SCTP's explicit EOR mode when sending and checking for the EOR flag when receiving. In fact, our implementation already supports messages of arbitrary size. Sadly, this hasn't been implemented in browsers as both Firefox and Chromium ignore the EOR flag completely which is a bug and an open issue @tuexen and I have discussed several times. Basically, @tuexen didn't want to open an issue before we have a patch. This bug is also the reason why we cannot send more than 64 KiB reliably (16 KiB in FF - Chromium interop, I've written about this in detail here) until it has been resolved.