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

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

From: Harald Alvestrand [mailto:[e-mail]]
Sent: Monday, October 27, 2014 5:03 PM

On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote:
+1 to make N-DATA optional.

Data channel provides a robust generic peer to peer communication channel. So, one can see that data channel may be used under non-webrtc contexts (like as in CLUE) as a general transport or as a replacement of native to SCTP to traverse firewalls. IMHO, majority of these use cases:
a. May just involve a single data channel (with possible multiplexing on top of it)
b. And may not use the DCEP either (both ends could assume same data channel stream id, this is similar to SCTP PPIDs).
We already made DCEP(b) as optional.

If an app is using just a single data channel then there is no real benefit in using N-DATA. Then why not make it optional? Also, as already pointed out, making it optional won’t break interop as it is still negotiated during SCTP setup time anyway.

Negotiation means that transport initiator gets to choose whether to use it or not.
This means that a responder has no choice in the matter.

In the situation where the responder knows better than the initiator what the usage is going to be, this is problematic.
<Raju>
IMHO, it is not just the responder knowing “better” which makes a scenario work, rather both have to agree on it. For example, if responder wants to have multiple data channels is no good if the originator does not want to support (CLUE use of data channels is an example of it). That’s why, in most cases I know it is the originator who offers capabilities and terminator gets to choose.
</Raju>



I would like to point out that there will be some webrtc applications which might just use one webrtc data channel for simplicity (and may use some multiplexing of different types of msgs/objects on top of it) or one is just sufficient as the app does not send/recv huge chunks of data. So, N-DATA isn’t needed for such webrtc clients either. Then why add burden to such webrtc implementations!?

You're confusing the webrtc application (what runs in the browser) with the webrtc implementation (the browser itself). Optional NDATA makes the browser *more* complex, since it has to expose API surface to let the application choose whether or not to offer NDATA, and it has to have code to decide whether or not to offer NDATA.
<Raju>
I am talking about 2 items:

1.       Making NDATA a MUST data channel draft? I could be wrong, but I thought this is the main discussion point in this thread! This is a burden on non-webrtc users of data channel. My understanding is data channels are meant to be used by non-webrtc as a general protocol. Please correct me if my understanding is not correct.

2.       Making NDATA a MUST for webrtc clients? I am not just talking about browser, but non-browser based native/hybrid webrtc clients (e.g. a thin webrtc client on a cable set top box) as well. Browsers can implement it as a MUST clause, no one is stopping that. But why mandate a set top box (or an IoT device) implement NDATA when it just wants to use a single data channel only?!

Let’s take an example: We keep NDATA a MUST. During SCTP setup, if NDATA is not supported at the peer then will the SCTP setup be abandoned? If the SCTP association is not abandoned then there is no point in making it a MUST where as in real practice it is not enforced as a MUST.
</Raju>

BR
Raju



From: rtcweb [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: Monday, October 27, 2014 3:11 PM
To: Harald Alvestrand; [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

Hi,

We shall not add burden just because there are bad programmers out there - they will anyway always manage to use our specs in a wrong way :)

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Harald Alvestrand<mailto:[e-mail]>
Sent: ‎27/‎10/‎2014 22:00
To: Christer Holmberg<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
On 10/27/2014 11:41 AM, Christer Holmberg wrote:
> Hi,
>
>>>>> Within the CLUE WG, we had a discussion regarding the following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt:
>>>>>
>>>>> "The support for message interleaving as defined in
>>>>>                 [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used."
>>>>>
>>>>> First, it is a little unclear what "the support SHOULD be used" means.
>>>> My understanding is that SCTP implementations supporting the extension will use it.
>>>> This is negotiated during the setup of the SCTP association.
>>> If it's done on SCTP level, why do we need to talk about it in the data channel draft?
>>>
>>> Is there a reason why it is important to use it for data channels? If so, does it apply to data channels in general?
>> NDATA was added in order to avoid head-of-line blocking on the transport (if I understand this correctly, until
>> this was added, sending a huge message would block the delivery of small messages on all channels until the huge message was fully delivered).
>>
>> Unlike Michael, I see no reason to make this a SHOULD; I think it should be a MUST, and the older
>> implementations in browsers should just be called out as non-conformant.
>>
>> That said, I think that data channels ought to interoperate successfully with implementations that don't support the
>> extension - but data channel implementations in WebRTC endpoints should be under a "MUST implement, MUST offer" ruleset.
> First, keep in mind that I am NOT talking about WebRTC endpoints (which is one reason we shouldn't call it webrtc data channel to begin with, but that's another story...), but ANY type of endpoint that wants to use a data channel.

I'm a bit self-centric on behalf of WebRTC, but I feel the other way -
that it might have been a mistake to float the option of saying "other
things can use these features", and that we should admit only arguments
that bear upon their usage in WebRTC.

I'm not sure I have WG consensus (even rough consensus) on this point,
however.
>
> Second, I am not talking about MUST support, but MUST use/offer.
>
> Assume I have a CLUE endpoint, which will use a data channel ONLY to transport CLUE messages. CLUE messages aren't that hugeto begin with, and there will be no blocking of small messages on other channels - as there are no other channels.
>
> So, why does the CLUE endpoint need to offer interleaving?

Flipping the question around - if a programming mistake in the
Javascript implementing a CLUE endpoint in a WebRTC browser happens to
send a multimegabyte-sized object down the (out of order) datachannel,
is it OK to have all the subsequent CLUE messages delivered 30 seconds late?



--
Surveillance is pervasive. Go Dark.






--

Surveillance is pervasive. Go Dark.