Re: [rtcweb] Open data channel issues

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

Please see inline comments.

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: Monday, March 03, 2014 4:46 PM
> To: Makaraju, Maridi Raju (Raju)
> Cc: Justin Uberti; Randell Jesup; [e-mail]
> Subject: Re: [rtcweb] Open data channel issues
> 
> On 03 Mar 2014, at 22:19, Makaraju, Maridi Raju (Raju)
> <[e-mail]> wrote:
> 
> > 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.
> You are right, if you consider RFC 4960. But using
> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00
> overcomes this limitation. You can have on each stream a message being sent
> in explicit EOR mode.
> Using an interleaving scheduler, they get interleaved on the wire. So you
> need the NDATA extension...

[Raju] 
Thanks for clarifying. Earlier it wasn't clear to me as EOR was referred to be EOR+NDATA. I was reading EOR as just EOR support without NDATA.
Yes, NDATA support is a must to avoid monopolization.
[/Raju]

> >
> > 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.
> I think the large message support with NDATA is sufficient to do whatever
> RTCWeb wants...

[Raju] 
Yes, I agree that NDATA is the final solution. But in the interim, application chunking per 16K size requires some chunking protocol at app.
Do we know the timeframe for NDATA support from browsers?
Until NDATA is available, to avoid monopolization one can use new PC as an alternative to application level chunking (which also require some kind of flow/congestion control).
Appreictae any comments on this approach.
[/Raju]

Best Regards
Raju