Re: [rtcweb] Open data channel issues

[Justin Uberti <[e-mail]>]

On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup <[e-mail]>wrote:

> On 3/3/2014 8:53 AM, Martin Thomson wrote:
>
>> On 3 March 2014 03:44, Randell Jesup <[e-mail]> wrote:
>>
>>> Hopefully so, though I hate forcing apps to include a bunch of code for
>>> backwards compat for a year or two (and many won't, or won't test it,
>>> etc).
>>> That hurts the feature.  And today no one has ndata.
>>>
>> Since WebRTC is behind a flag, I don't find this particularly
>> convincing.  We can implement ndata.
>>
>
> I don't understand the "behind a flag" comment; an app using DataChannels
> for anything variable-length (unless with low bounds) must care until all
> old implementations are gone.  Since we already have DataChannel impls in
>  ESR releases, there's no avoiding this if we rely on that (even worse,
> since this undefined property doesn't exist yet (let alone in ESR), the app
> has to handle that case as well).  Or add browser and version sniffing to
> all the apps...
>
>
>  I think that we could even remove our temporary length restriction.
>>
>
> Sure, we can.  This will reduce or eliminate source changes for apps that
> don't care about interleaving, which is a plus.  It will cause total stall
> of all other DataChannels during  transmission of one large message, which
> some applications would be ok with, and others would not, and so those that
> would not would have to somehow deal with it.
>
> So, applications that are ok with blocking other channels with large sends
> could be allowed to send arbitrary-sized messages, and receivers would be
> required to receive them (without chunking). Applications that do care
> about other channels would need to restrict their sending size when ndata
> isn't available at both ends.  We really only need to know if ndata is
> available and expose that fact to the application, not a receive size from
> the receiver.
>
> So this plan would be:
> 1) We expose ndata being agreed to (currently == false);
> 2) We turn off the PPID chunking in Firefox (and live with ESR24 and
> current revs of Firefox not being compatible; see 2a)
> 2a) we make sure the app can detect if the local client has the ndata
> property at all (supports this solution).
> 3) We make sure Chrome and Firefox both implement both EOR sending and EOR
> reception and unlimited (or virtually) send/receive sizes.
>
> For bonus points, on EOR reception of a blob, spool it to disk in the
> browser (if over some limit perhaps), and on EOR send of a blob, optimize
> it to avoid send-side memory hits and performance issues.
>
> This will break large send/receive between Chrome and current/older
> Firefox - but those are broken today by Chrome not implement PPID chunking
> and Firefox doing so.  Firefox can still fall back on PPID chunking if it
> knows it's talking to another Firefox until we decide that this no longer
> matters.  I could be wrong, but I think Chrome doesn't support EOR sending
> currently; I know Firefox doesn't since we were using PPID chunking, so
> we'd need to add that.
>
> Once ndata is supported, all will work well, and applications that didn't
> care about interleaving don't have to change, and those that do will
> trigger on ndata and switch (and they can test ndata==true mode reasonably
> well by forcing it in the app, since send(large) will work).


While I agree with the final outcome of #3, I don't think going down the
1/2/2a path makes sense, since it leads to an additional intermediate state
over the current situation. i.e. we end up with 3 states:
a) today: max safe send is 16 KB
b) soon: ndata exists, but large sends lock out other sends
c) final: ndata exists, and large sends work OK

I would rather maintain a) or similar for now (using the max-message-size
param) and jump to c) when we have the right stuff in SCTP.

>
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>