Re: [rtcweb] Open data channel issues

[Randell Jesup <[e-mail]>]

On 3/3/2014 1:53 AM, Michael Tuexen wrote:
> On 03 Mar 2014, at 02:42, Randell Jesup <[e-mail]> wrote:
>
>
>> EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).
> If you want to send messages larger than the socket send buffer, you must use the explicit
> EOR more. This is independent from using NDATA or not.

right.

> If you use NDATA, you can have on each outgoing stream a single message (order or unordered)
> being sent using explicit EOR mode and the calls can be interleaved. I don't think I have
> tested this up to know, but this is how it should work.
>
> rrs@: Just to double check: Am I right? Please note that RTCWeb doesn't use ordered and
>        unordered on the same stream, and you don't need to send more than one message with
>        explicit EOR on the same stream at the same time. Therefore the above simplification...

If this is the case, this should deal with the issue I believe, with one 
caveat for the W3 layer:

If we can only send one at a time, we get an issue where we call 
channel.send(blob1); channel.send(blob2);

the JS interface to send() is synchronous and can't block.  This implies 
that if send(blob1) hasn't completed, the send(blob2) can't start, and 
all following send()s must also be buffered in memory. For a blob, since 
a blob reference is read-only, this is likely ok (need to verify what 
happens if we haven't read the blob into memory - if this isn't the 
case, we have a problem).  For sending an ArrayBuffer (or string), we'll 
have to snapshot the buffer at send() time if it's queued since the 
referenced data may change.  However, this really isn't anything that 
new, since if the SCTP buffers are full you have to do something similar 
anyways, even without any messages using fragmentation.

I presume from your comment (since it wasn't entirely clear) that if I 
have channel.send(blob1); channel.send("foo") that "foo" can't be sent 
until blob1 has been fully transmitted (has hit EOR at the send side), 
even though "foo" doesn't require fragmentation, and so all send()s for 
a channel during a fragmented send() must be copied and queued.

>> Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.  So ndata will allow us to expand the max-sending size to
> This API work is part of getting NDATA implemented. Randall has implemented it, we do have
> code, but it needs some testing and cleaning up in the API which supports the scheduling...

So the last issue would be backwards compatibility.  If today an app 
must be written to query (via an unspecified W3 property) the max size 
you can reliably send() to the other side, then it must buy into (and 
test!) that functionality now and until it's pretty certain that all 
non-compliant implementations are gone.  This can take a while, even if 
you assume people update promptly, due to things like Firefox "ESR" 
releases (Extended Support for businesses, schools, etc).  Thes are 
valid for most of a year, and if we land ndata support right after one 
is created it could be closer to 1-1.5 years before if even starts to 
reach clients - and it may take even more time for all ESR users to 
approve/test it and update.

The arguments about having all the apps be required to implement their 
own fragmentation, etc for a considerable period adds lots of complexity 
to the apps.  Implementing the PPID chunking as the stopgap (and 
retiring it once ndata is universal) means the API to the application 
remains stable and simple.  Since all DataChannel implementations must 
implement queuing of JS send()s (since the SCTP bufferspace may be 
full), it's easy to support PPID fragmentation if you don't worry about 
memory-use optimization).  ndata not being available yet highlights this 
issue.

>> min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).  It does not allow us to expand the size to any useful Blob size.
> Please note that you never have a limitation of the receive buffer send size, since SCTP
> would use partial delivery. So other-sides-max-receive-size is only relevant if there are
> buffering limits on top of SCTP.

I was referring to the SDP value for "minimum value I guarantee receiving".

We would need to specify that if ndata is agreed to (I presume we know 
that) that the application would be told an "infinite" value for 
max-I-can-receive (since we can't use the value from the SDP, as that 
predates the two sides creating the association and negotiating ndata).  
I don't want to renegotiate just to remove the max SCTP receive size.

   Randell

-- 
Randell Jesup -- rjesup a t mozilla d o t com