New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTCSctpCapabilities maxMessageSize issues #626
Comments
In WebRTC 1.0, the maxMessageSize attribute is an unsigned long, so there is a potential compatibility issue: |
WebRTC 1.0 also does not clarify the |
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.
|
Thanks Michael. Taking into account that implementations can set |
Proposed resolution: change to unsigned long |
And maybe adding something like this to the description:
|
@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. |
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
Furthermore, I probably should have mentioned earlier that draft-ietf-mmusic-sctp-sdp does handle the Edit: Sorry for all the editing. |
@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. |
@lgrahl @pthatcher While draft-ietf-mmusic-sctp-sdp does handle |
@aboba I'm not sure if I understand your question correctly, but basically this value needs to be stored and checked in 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. |
@robin-raymond I overlooked your point about no EOR support. It's vital that we know whether we talk about EOR when receiving or EOR when sending because one is required and one is not. Every SCTP-based data channel implementation must look at the EOR flag when receiving messages or it will violate the message-oriented principle of SCTP and data channels. This is exactly what pretty much every implementation out there currently does (violate). You've mentioned that TCP supports arbitrary sized messages by sending only parts of the buffer. It's the same for SCTP which will also send only parts of the buffer and not all or nothing. That's why the EOR flag exists and why looking at it is so essential even if an implementation doesn't use the explicit EOR mode for sending. Back to the main topic: Granted, by allowing |
Ping! Any new thoughts/comments? |
By the way, we have a working implementation that can handle messages of arbitrary size and supports |
I think the biggest issue is going to be the lack of support for EOR and backwards compatibility until it becomes prolific. We may need an EOR usage setting for compatibility. Also does there need to be any guidelines to how to handle larger message that are received but still incomplete due to missing segments of the larger message in a lossy sctp mode? I'm not sure if this is covered via RFC(s) already or not or if it's possible to have more than one larger messages being reassembled at one time with missing segments of the larger message still outstanding. |
I don't see any backwards compatibility issues. Handling EOR and reassembling messages when receiving isn't optional, it never was. Let's dig into SCTP's RFCs for an explanation: RFC 4960, section 6.9. states
The SCTP API (RFC 6458) clarifies that this has to be done by the application to some extent (I don't know why this section isn't mentioned for
In case of usrsctp, if you use the callback API, a call to Explicit EOR when sending is an API mode that can be activated in the SCTP API (see RFC 6458, section 8.1.26 and has no implications on compatibility.
That question is partly answered by section 3.1.4 in the SCTP API (RFC 6458)
More precisely, RFC 6458, section 8.1.20 allows the use of three different levels which control the application's desired interleave behaviour. Note that this does not change SCTP's behaviour - there's nothing to negotiate here. It simply controls how the API behaves towards the application. Broadly speaking level IIRC when message chunks of a message have already been handed out but there will be no retransmissions for the remaining chunks, the Implementations that can send messages of arbitrary size still have to obey the maximum message size when sending, so I don't see an incompatibility there either. The default maximum message size in WebRTC's SDP is 64 KiB which is exactly what current implementations (with the bug mentioned above) can handle. (@tuexen Please correct me if I'm wrong with any of my statements above.) |
@lgrahl I'm well aware EOR is not optional, but sadly it was not implemented correctly everywhere so to assume it exists at the moment is problematic for compatibility in the real world so while we should fix the spec, this is an ongoing concern; i.e. I do agree that we should have a max message size as an unsigned long (although I don't necessarily agree with the meaning of "0" as unlimited, I'd rather the value be "unset"). As for the fragment interleave, that's exactly what I was concerned about - what surface control do we need to expose to the application to control the expected behaviour of the engine. Do you have specific proposal for this? |
Let's put the discussion about
I don't think I understand what you mean. Can you rephrase? What's application and what's engine for you? Also, what kind of proposal do you mean - I guess for the ORTC spec? I'm a bit confused, sorry. :) |
The EOR issue is unrelated to the maxMessageSize. My point was that allowing a larger max message size indirectly brought up the issue that EOR is a problem for compatibility in the real world at the moment because of lack of compliance. Any API that doesn't offer an override to disable EOR may cause interaction problems with non-compliant remote parties even though "must" is specified. You may be right, the remote party indicating a low maxMessageSize might be sufficient to never cause the EOR incompatible issue to become a problem when connecting an EOR compliant implementation with the an non-compliant remote party. Certainly the spec should assume all parties are compliant but ... the reality is they aren't. Application = anything high layer calling an implementation of the ORTC spec. Engine = any implementation of the ORTC spec. |
Ah, okay. I don't see a need for an EOR on/off switch as it's working perfectly fine if Sending from EOR-compliant to non-EOR-compliantEOR-compliant engines can only send 64 KiB to non-EOR-compliant engines. The reason why 64 KiB works is because Receiving from non-EOR-compliant to EOR-compliantLet's summarise existing compatibility issues for non-EOR-compliant engines that talk to each other before we talk about EOR-compliant engines: All existing WebRTC engines I know ignore or don't even provide the maximum message size attribute in the offer/answer SDP the last time I checked. Chromium can send up to 256 KiB, everything above raises an error and closes the data channel. But when receiving on either Chromium or Firefox, this 256 KiB message appears as four different 64 KiB messages because these engines don't look at the EOR flag. Furthermore, Firefox can send messages of arbitrary size and uses the deprecated fragmentation/reassembly mode based on PPIDs. And guess what, Chromium doesn't support that mode and delivers the chunks to the application as if they were different messages. That's the 16 KiB Firefox-Chromium interop limitation in a nutshell. So, these two browsers are already highly incompatible to one another with lots of corner cases if you send more than 16 KiB sized messages. Chromium is even incompatible to itself. The whole message-oriented principle shredded to pieces. (Sorry for being dramatic :)) EOR-compliant engines provide the maximum compatibility because they a) reassemble the 256 KiB messages that Chromium sends and b) can add the deprecated fragmentation/reassembly mode as it is very simple to add if the engine is already EOR-compliant. This provides compatibility with Firefox. So, to sum it up: If EOR-compliant engines provide much better compatibility to existing engines than non-compliant EOR engines. Why have a switch in ORTC to turn if off? |
I'm working with the guys at Mozilla to bring EOR into Firefox's WebRTC data channel implementation. Maybe we can convince you with a real world example that EOR doesn't pose a threat to compatibility. Will keep you posted. |
So, this is the plan we have worked out for Firefox regarding EOR (keep in mind, I'm talking about WebRTC here but I will explain the effect it will have for ORTC interop):
Compatibility: EOR & non-EOR
Compatibility: WebRTC-ORTC Shims & API
Are there open questions regarding EOR? |
I see two problems with the
maxMessageSize
attribute ofRTCSctpCapabilities
: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.
The text was updated successfully, but these errors were encountered: