Re: [rtcweb] Meaning of SHOULD support/use interleaving

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

+1 for making data channel as webrtc independent.
+1 for making NDATA a MUST for webrtc use of data channels only.
   As we have seen in recent posts NDATA is not risk free and has "baggage" associated to it.
My detailed view is explained in the post:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13322.html

BR
Raju


> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Christian Groves
> Sent: Tuesday, October 28, 2014 5:55 PM
> To: [e-mail]
> Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
> 
> +1 for removing webrtc from data channel and making it clearer that it
> can be used as a general mechanism. That's why I thought there should be
> a separate ALPN in draft-ietf-rtcweb-alpn-00 for data channel only usage
> rather than saying SRTP may be absent.
> 
> Regards, Christian
> 
> On 29/10/2014 9:14 AM, Paul Kyzivat wrote:
> > Mary pointed out an important typo in this message. Correction inline.
> >
> > On 10/28/14 4:13 PM, Paul Kyzivat wrote:
> >> (This thread has gotten long, and its hard to figure where to jump in.
> >> I'm just replying to the last message I see, but am commenting on the
> >> thread in total.)
> >>
> >> Regarding data channels being webrtc-specific:
> >>
> >> I don't see it that way. Webrtc has opened up restricted communication
> >> among browsers. If you want to talk to a browser, you have few choices,
> >> and this is the one that is "general purpose". So any application that
> >> sometimes might need to run in a browser is a likely candidate for data
> >> channels. And then, when non-browser versions of that app are talking to
> >> one another, it will be most practical to use the same mechanism.
> >>
> >> That is why CLUE is using data channels - even if we think that *most*
> >> of the endpoints won't be in browsers.
> >>
> >> Regarding NDATA:
> >>
> >> ISTM that SCTP just screwed up in not including the NDATA features in
> >> the base protocol. Going forward, it always should be included in new
> >> implementations. Since data channels are being defined after NDATA, it
> >> is perfectly reasonable for data channels to require NDATA support.
> >>
> >> IIUC, while NDATA allows fragmentation to avoid head of line blocking,
> >> that doesn't mean the messages will be fragmented unnecessarily. If you
> >> are only using one channel I *think* it likely that even a large message
> >> won't be fragmented. So it will be harmless insurance.
> >>
> >> Christer said that since CLUE only needs one data channel there is no
> >> need for NDATA. Someone specifying BFCP over data channel might reach a
> >> similar conclusion for it. But there is nothing to prevent an
> >> application that implements both CLUE and BFCP. Independently they
> >> wouldn't need NDATA, but together they would.
> >>
> >> So I am in favor of making NDATA mandatory to implement, offer, and
> >> accept for data channels.
> >>
> >> But I would still like the data channel spec to acknowledge that, while
> >> webrtc is a *very* important client, that the protocol solely for
> >> webrtc. And with that in mind I would like to see "webrtc" removed from
> >> the name of the protocol. (E.g., in the SDP m-line.)
> >
> > What I meant to say in the last paragraph is:
> >
> > But I would still like the data channel spec to acknowledge that,
> > while webrtc is a *very* important client, that the protocol *is not*
> > solely for webrtc. And with that in mind I would like to see "webrtc"
> > removed from the name of the protocol. (E.g., in the SDP m-line.)
> >
> >     Thanks,
> >     Paul
> >
> >
> >> On 10/28/14 1:53 PM, Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>>      >>> I am not suggesting different flavors - I am suggesting to
> >>> make
> >>>     the usage of
> >>>      >>> interleaving optional. Other SCTP features are also optional
> >>>     (including reliability, ordering etc).
> >>>      >>>
> >>>      >>> Where are these things optional? According to
> >>>      >>>
> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section
> >>>      >>> -6.1 an implementation MUST implement PR-SCTP and the support
> >>>     of the
> >>>      >>> FORWARD-TSN chunk will be negotiated similar to the NDATA
> >>>     chunk. I don't see a difference, especially not if we move to MUST
> >>>     support NDATA.
> >>>      >>
> >>>      >> For example, section 6.1 says:
> >>>      >>
> >>>      >>      "The partial reliability extension defined in [RFC3758]
> >>>     MUST be supported."
> >>>      >>
> >>>      >> However, in CLUE we say that a CLUE entity MUST NOT *use* the
> >>>     extension, as all CLUE messages are required to be sent reliably.
> >>>      >
> >>>      > That is OK. However, support for PR-SCTP MUST be there and it
> >>>     will be negotiated. You just never send a message with partial
> >>>     reliability. At least this is my understanding...
> >>>
> >>>     So, can the same be done for interleaving? I.e. the support MUST be
> >>>     there, but e.g. CLUE entities can choose not to use it?
> >>>
> >>>     Note that my issue is not about support, it's about usage :)
> >>>
> >>> What resource is being conserved by not just requiring it?
> >>>
> >>> I don't know. The task is to figure out whether there are *technical*
> >>> reasons to mandate usage of certain SCTP features for CLUE.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb