Re: [rtcweb] Open data channel issues

[Randell Jesup <[e-mail]>]

On 3/3/2014 12:54 PM, Justin Uberti wrote:
>
>
>
> On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 3/3/2014 8:53 AM, Martin Thomson wrote:
>
>         On 3 March 2014 03:44, Randell Jesup <[e-mail]
>         <mailto:[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.

So, is there any significant advantage to using a max-message-size param 
(with >16K) as an interim step?  You get 3 similar steps (though perhaps 
with a smaller lockout).

To take your suggestion:
a) applications assume 16KB if ndata wasn't negotiated (per the current 
suggestion)
b) implement ndata and EOR support in the browsers, and drop the 16KB 
limit when ndata is negotiated.
All this needs is "is ndata supported by this association" exposed to 
the app; no sdp changes needed.  (One less dependency!)

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