Re: [rtcweb] Open data channel issues

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

Sorry to jump in from middle of nowhere in this interesting conversation. I couldn’t resist providing this feedback and I hope it is useful.

First, on “EOR solving monopolization issue”:
I could be wrong, but I am not sure how EOR based approach avoids SCTP link monopolization?! Per my understanding EOR is a local send () utility rather than receive side utility and it is implemented on top of base SCTP RFC (so no indication of special EOR in SCTP headers other than base SCTP RFC B/E fragment indication bits). Once a send () with EOR set to false is called, on a stream id, the SCTP link is monopolized until send () on same stream id with EOR set to true is called; so same limitation exist.  EOR allows sending side to start sending chunks without waiting for complete data. EOR has no impact on receiving side, the SCTP stack waits for last chunk (which is the result of sending side setting EOR=true) and delivers entire message to app.

New PC approach:
If an application is sensitive to SCTP link monopolisation then there is another option it can consider – use of separate new PeerConnection (PC) for the data channel(s) which may monopolize the link.
Depending on how an application is designed, using a new PC could be simpler than having an application level chunking protocol (fragmentation and reassembly).  If app needs such “heavy” data channel infrequently then it can create new PC as needed; if it is needed frequently then a dedicated PC can be allocated and keep it open all the time.

One disadvantage with application level chunking protocol is both the peers need to use it; so it may not work between clients of different types or same clients with different versions. New PC based approach obviously does not have this issue as no chunking is involved.

At first, new PC approach may appear heavy weight wrt # of PCs in use (which I don’t think an issue on browsers), ICE overhead for new PC etc. But in comparision to application level chunking new PC approach may not be that bad.

Please see additional comments inline.

-Raju

From: rtcweb [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: Monday, March 03, 2014 11:54 AM
To: Randell Jesup
Cc: [e-mail]
Subject: Re: [rtcweb] Open data channel issues



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.
[Raju] This requires PeerConnection API to indicate EOR during send(). Right? Which may be useful in some cases where app wants to send partial data as it is available/ready. But as explained above, in my opinion EOR won’t solve SCTP link monopolization and unncessarily introduces overhead at application.

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.
[Raju] With 16KB safe size won’t applications have to have their own chunking protocol? as per my understanding EOR won’t solve the monopolization issue, so it adds no value.

To avoid applications coming up with their own chunking protocol, an attractive alternative would be to use the PPID chunking that’s already mentioned abovr and implemented by Firefox. Then the issue of interworking pushed down to browser from application area. But this obviously requires browsers on both the ends to support this PPID based chunking.

-Raju



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