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

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 13:12:48 +0000

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.

Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use interleaving, even if the characteristics of the protocol wouldn't require it?

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 15:10:30 +0100

On 27 Oct 2014, at 14:12, Christer Holmberg <[email-masked]> wrote:

> “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.
Whether messages are interleaved or not depends on the stream scheduler. This is
a sender side only decision. The receiver has to deal with it.
It is not a MUST, since there are implementations now in use which don't support
the extension.

Best regards
Michael
>  
> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use interleaving, even if the characteristics of the protocol wouldn’t require it?
>  
> Regards,
>  
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 14:19:11 +0000

Hi,

> 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? 

Regards,

Christer

Whether messages are interleaved or not depends on the stream scheduler. This is a sender side only decision. The receiver has to deal with it.
It is not a MUST, since there are implementations now in use which don't support the extension.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Oct 2014 11:23:14 -0700

> 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.

-- 
Surveillance is pervasive. Go Dark.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 18:41:17 +0000

Hi,

> 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. 

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?

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 20:49:57 +0100

> If it's done on SCTP level, why do we need to talk about it in the data channel draft? 
We need to specify somewhere that the extension is used and how to map the priorities
of data channels to some protocol mechanism. This is done in this document.
> Is there a reason why it is important to use it for data channels? If so, does it apply to data channels in general? 
As it is written right now: yes.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 20:52:07 +0100

> called out as non-conformant.
I personally also prefer a MUST, but the reason I gave was the one which
was used in the discussion resulting in a SHOULD. Since this is also brought
up by David, we possibly need to reconsider the issue and change it to a MUST.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 20:55:16 +0100

> So, why does the CLUE endpoint need to offer interleaving?
As far as I know we don't have different flavours of data channels. At least right now.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Oct 2014 13:00:51 -0700

> 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…

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.
> 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?

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 20:05:52 +0000

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).

We CAN write/reference guidelines on when it DOES make sense to use interleaving.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Michael Tuexen<mailto:[email-masked]>
Sent: ‎27/‎10/‎2014 21:55
To: Christer Holmberg<mailto:[email-masked]>
Cc: Harald Alvestrand<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 21:10:39 +0100

> 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.

Best regards
Michael
> From: Michael Tuexen
> To: Christer Holmberg
> Cc: Harald Alvestrand; [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Oct 2014 20:10:46 +0000

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:[email-masked]>
Sent: ‎27/‎10/‎2014 22:00
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 27 Oct 2014 20:31:26 +0000

+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.

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!?

BR
Raju

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

Hi,

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Oct 2014 22:19:48 +0100

> 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 o…
Are you implementing this? I would say that adding N-DATA to an SCTP implementation with support
for Stream Reconfiguration and PR-SCTP does not increase the complexity substantially...

Best regards
Michael
> From: Harald Alvestrand
> To: Christer Holmberg; [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Oct 2014 15:02:49 -0700

On 10/27/2014 01:31 PM, Makaraju, Maridi Raju (Raju) wrote:
> 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:
>
> b. And may not use the DCEP either (both ends could assume same data
> channel stream id, this is similar to SCTP PPIDs).
>
> 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.

>  
>
> 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.

If you're arguing that we should make NDATA optional to implement for
browsers ..... that is an issue that I thought we had already settled.

>  
>
> BR
>
> Raju
>
>  
>
>  
>
> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* Monday, October 27, 2014 3:11 PM
> *To:* Harald Alvestrand; [email-masked]
> *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
>
> ------------------------------------------------------------------------
>
> *From: *Harald Alvestrand <mailto:[email-masked]>
> *Sent: *‎27/‎10/‎2014 22:00
> *To: *Christer Holmberg <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Subject: *Re: [rtcweb] Meaning of SHOULD support/use interleaving
>
> >>>>> Within the CLUE WG, we had a discussion regarding the following
> statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt:
> >>>>> 
> >>> 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).
> >>
> >> 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.
>
> > 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.
> >

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 17:25:49 -0700

On 27 October 2014 15:02, Harald Alvestrand <[email-masked]> wrote:
> 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.

Yes.  I don't understand why we would want to say no to making NDATA
mandatory for browsers, other than to note that not all peers will
support NDATA.

SCTP without NDATA simply isn't fit for purpose.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Oct 2014 17:29:26 -0700

On Mon, Oct 27, 2014 at 5:25 PM, Martin Thomson <[email-masked]>
wrote:

> the

I agree with this. Let's require what we need.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Mon, 27 Oct 2014 17:39:11 -0700

> I agree with this. Let's require what we need.

+1. The fewer optional things we have, the more likely things will Just
Work.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 08:22:02 +0000

Hi,

If people want to make NDATA mandatory for browsers, fine.

But, my question is whether there is a technical reason to mandate its usage for CLUE, if CLUE is the only usage of the data channel?

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 28. lokakuuta 2014 2:39
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

On Mon, Oct 27, 2014 at 5:29 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 27, 2014 at 5:25 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

+1. The fewer optional things we have, the more likely things will Just Work.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 28 Oct 2014 11:58:41 +0000

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

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>

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, October 27, 2014 3:11 PM
To: Harald Alvestrand; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving

Hi,

Regards,

Christer

--

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 28 Oct 2014 12:07:34 +0000

> > 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:
> 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.
> >
> 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!?

<Raju>
I don't think the question is really about if NDATA adds complexity or not.
NDATA is a new capability to be added to SCTP stacks; and adding it takes
resources to develop, test, deliver, deploy/update.

As I just responded to Harald's post, we need to look at it from
data channel use in non-webrtc contexts and also data channel use
for non-browser webrtc clients. Just focusing on webrtc+browser alone
is not fair as not all the webrtc or non-webrtc data channel implementations
can keep up with the same pace as browsers do; also they don't have
resources like browser companies do!!

</Raju>

BR
Raju

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Oct 2014 06:27:01 -0700

On 10/28/2014 04:58 AM, Makaraju, Maridi Raju (Raju) wrote:
>     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:
>
>     b. And may not use the DCEP either (both ends could assume same
>     data channel stream id, this is similar to SCTP PPIDs).
>
>     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.
>
>
> 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>
>
>
>  
>
> 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>
>
> 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.
>

Your understanding may be right or wrong, but it's different from mine.

Data channels are created to be useful for WebRTC. That's their purpose
in being created, so WebRTC requirements take precedence over all other
requirements.

NDATA makes them more useful for WebRTC (or, as Martin put it, "without
NDATA, they're not fit for purpose").

Optional NDATA makes things more complex for WebRTC.

Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I
think NDATA should be mandatory.

> 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.
>

In general, when an application connects to something that does not
conform to the spec for the protocol he's using, "all bets are off".

Implementations are free to handle this situation whatever way they want.

Note: So far, I've seen *zero* evidence that the burden of implementing
NDATA is significantly higher than the total effort spent in writing
updates on this thread. For 90+% of all implementors, not implementing
NDATA is a larger effort than implementing it, because the libraries
they use will support it, so they have to take action to take it out.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 13:51:07 +0000

Hi,

> 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.

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 28 Oct 2014 16:06:36 +0100

> 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...

Best regards
Michael

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 15:46:40 +0000

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).
>>> 
>>> 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.
>> 
> 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 :)

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Oct 2014 09:25:32 -0700

On Tue, Oct 28, 2014 at 8:46 AM, Christer Holmberg <
[email-masked]> wrote:

> >>> 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.
> >>
> >> 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?
>

What resource is being conserved by not just requiring it?

-Ekr

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 28 Oct 2014 17:02:44 +0000

Please see my comments inline.

From: Harald Alvestrand [mailto:[email-masked]]
Sent: Tuesday, October 28, 2014 8:27 AM

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.

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!?

Data channels are created to be useful for WebRTC. That's their purpose in being created, so WebRTC requirements take precedence over all other requirements.
<Raju2>
IMHO, I don't think that is how IETF worked; you produce something which is generally useful than very specific to one particular use case without giving up on too much for the original purpose. In fact, WebRTC is a huge beneficiary of it!! IMHO, making data channels transport a generic mechanism is part of that process.
</Raju2>

NDATA makes them more useful for WebRTC (or, as Martin put it, "without NDATA, they're not fit for purpose").

Therefore, seen from a WebRTC viewpoint, speaking in the RTCWEB WG, I think NDATA should be mandatory.
<Raju2>
This is related to webrtc vs. non-webrtc use of data channels. To give data channels independence (sorry, I did not mean in a dramatic way :)) from webrtc, can we make data channel drafts generic and compliancy aspects of it into a webrtc specific section/draft; this (separate draft) is how it is done for RTP transport. Such webrtc compliance for data channels can be part of the same data channel draft but a new webrtc specific section or in a new/existing webrtc specific draft (webrtc/data-channel overview draft). Similarly CLUE specific compliance can be in a separate section of the data channel draft.
</Raju2>

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.

In general, when an application connects to something that does not conform to the spec for the protocol he's using, "all bets are off".

Implementations are free to handle this situation whatever way they want.
<Raju2>
This item is specific to data channel requirements for webrtc use. If a requirement is a MUST then how can it be implementation specific? Then why put a requirement as MUST but still allow implementations to have different behavior?
</Raju2>

Note: So far, I've seen *zero* evidence that the burden of implementing NDATA is significantly higher than the total effort spent in writing updates on this thread. For 90+% of all implementors, not implementing NDATA is a larger effort than implementing it, because the libraries they use will support it, so they have to take action to take it out.
<Raju2>
The 90% can then always support NDATA... no issue with that. But why make it a burden for rest of the 10% (these are the ones who may be constrained by various resources)? IMHO, we don't add MORE work for an implementation just because it already has LOTs of work to do anyway! It should be other way around, since there is so much stuff mandatory already why not go easy on the stuff which may not be needed by some applications!!?
</Raju2>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Oct 2014 17:53:19 +0000

Hi,

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Oct 2014 16:13:02 -0400

(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.)

	Thanks,
	Paul

On 10/28/14 1:53 PM, Christer Holmberg wrote:
>      >>> 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.
>      >>
>      > 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?
>
> 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
>
>
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 28 Oct 2014 20:52:56 +0000

> What resource is being conserved by not just requiring it?

8 bytes per packet (for MID+FSN).

Michael, the current NDATA draft requires it to be used for all messages if negotiated. Can’t this be relaxed / optimized to use it for all *fragmented* messages but use DATA for non-fragmented messages to avoid the 8 byte overhead for small messages (like game telemetry/control, an often cited use of data channels).

The current NDATA draft also says you can’t interleave fragmented messages in a stream, so head of line blocking remains for all fragmented messages, while only small non-fragmented messages can avoid it. This dilutes the utility of NDATA, perhaps enough to make apps that really care about head of line blocking to implement their own app layer fragmentation with messages well below common MTUs, hence defeating NDATA. Can’t this also be relaxed since MID is part of the NDATA extra header?

If those two issues are resolved, I see no argument against making NDATA a MUST in data channels.

Mo

PS. Some believe data channels will be more widely used than WebRTC media (webtorrent, etc.), so it does make sense to consider the desirable properties of a general peer-to-peer transport, and drop the WebRTC prefix when talking about data channels.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 28 Oct 2014 22:11:38 +0100

> Michael, the current NDATA draft requires it to be used for all messages if negotiated. Can’t this be relaxed / optimized to use it for all *fragmented* messages but use DATA for non-fragmented mes…
You can bring this up at the tsvwg mailing list. However, we normally do not optimize for byte saving... Mixing
both makes the processing harder... Maybe we can use a bit in the flags to indicate if the additional fields are
there...
> The current NDATA draft also says you can’t interleave fragmented messages in a stream, so head of line blocking remains for all fragmented messages, while only small non-fragmented messages can av…
This would only make sense for messages marked as unordered... For ordered it doesn't make sense.
> If those two issues are resolved, I see no argument against making NDATA a MUST in data channels.
Please let us discuss NDATA issues on the tsvwg mailing list...

Best regards
Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Oct 2014 18:14:19 -0400

Mary pointed out an important typo in this message. Correction inline.

> 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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 28 Oct 2014 22:28:52 +0000

On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" <[email-masked]> wrote:

> Michael, the current NDATA draft requires it to be used for all messages if negotiated. Can’t this be relaxed / optimized to use it for all *fragmented* messages but use DATA for non-fragmented mes…
You can bring this up at the tsvwg mailing list.

Mo: Will do.

However, we normally do not optimize for byte saving... Mixing
both makes the processing harder... Maybe we can use a bit in the flags to indicate if the additional fields are
there...

Mo: Type should already be enough without flags.

Mo: The restriction applies to unordered as well as ordered. Even for ordered, it does make sense to avoid head of line blocking at the sender. 

Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits outweigh its costs. The current draft does not pass that bar for me. If my app cares about HOL blocking, NDATA is not very useful, so my app must internally fragment, hence NDATA actually becomes harmful (8 bytes closer to exceeding MTU, forcing SCTP fragments and hence risking HOL blocking).

Best regards
Michael

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Oct 2014 09:54:32 +1100

+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:
> 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
>
>
>>>      >>> I am not suggesting different flavors - I am suggesting to 
>>> make
>>>     the usage of

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 29 Oct 2014 00:01:37 +0000

+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:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, October 28, 2014 5:55 PM
> To: [email-masked]
> >>> I don't know. The task is to figure out whether there are *technical*

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 29 Oct 2014 01:27:46 +0000

Moved to tsvwg:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12892.html

On 10/28/14, 6:28 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" <[email-masked]<mailto:[email-masked]>> wrote:
On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 29 Oct 2014 11:05:25 +0100

> Mo: The restriction applies to unordered as well as ordered. Even for ordered, it does make sense to avoid head of line blocking at the sender. 
I don't understand how you can do it for ordered. The sender sends a large message on stream 0 and after that
a small on stream zero. For both ordered delivery is request. So the receiver can't deliver the second before the
first.
> Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits outweigh its costs. The current draft does not pass that bar for me. If my app cares about HOL blocking, NDATA is not ver…
I don't understand the point when I look at the API for data channels... Only for sending messages
on a data channel not requiring ordered delivery. However, the intention of NDATA is to mitigate
the impact of one data channel on others belonging to the same peer connection. This goal is met.

Best regards
Michael

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 29 Oct 2014 20:17:14 +0000

Hi Michael,
I moved to tsvwg as requested. See my reply to Karen, and one reply inline.
http://www.ietf.org/mail-archive/web/tsvwg/current/msg12899.html

For rtcweb, the main point is this. Will rtcweb apps care about blocking on potentially fragmented messages? I think they definitely will, if they care about blocking at all. Even simple JSON objects, which seem like natural message payloads, can easily exceed common MTUs. It doesn’t take huge file transfers to require fragmentation.

Cheers,
Mo

On 10/29/14, 6:05 AM, Michael Tuexen <[email-masked]<mailto:[email-masked]>> wrote:
On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

Mo: Blocking sender transmission is very different from blocking receiver delivery to the app. It is wrong to assume all ordered protocols should block sender transmission out of order. Windows and SACK improve performance of ordered protocols despite the receiver blocking delivery to the app.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 30 Oct 2014 19:53:56 +0100

> http://www.ietf.org/mail-archive/web/tsvwg/current/msg12899.html
Great, thanks. I'll respond, but I'm really slow right now, since my day job
needs more time than I would like...
> For rtcweb, the main point is this. Will rtcweb apps care about blocking on potentially fragmented messages? I think they definitely will, if they care about blocking at all. Even simple JSON objec…
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will block other
   messages sent on the same data channel. Since it is an ordered channel, this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small one after
   that, there is no statement made in which these messages would be delivered.
   Are you focussing on this and do you want to require some sort of reordering?

Best regards
Michael
> 
> Cheers,
> Mo
> 
> On 10/29/14, 6:05 AM, Michael Tuexen <[email-masked]> wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 30 Oct 2014 22:55:52 +0100

> For rtcweb, the main point is this. Will rtcweb apps care about blocking on potentially fragmented messages? I think they definitely will, if they care about blocking at all. Even simple JSON objec…
After thinking about it a bit more:

Assume an unordered data channel dc and the application calls
dc.send(big_msg);
dc.send(small_msg);
How do you decide whether the intended behaviour is either
(a) deliver big_msg before small_msg
(b) deliver small_msg before big_msg
I don't see any way in the W3C API to indicate this. Both alternative
might the appropriate in different scenarios.

Best regards
Michael

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 31 Oct 2014 18:17:55 +0000

Hi Michael,
Merging your points and replying here since we are firmly in rtcweb cases.
We can summarize for tsvwg once concluded (if we reach any conclusion).

Consider real rtcweb apps that have many potentially large blobs to
transfer, like proxy browsing, webtorrent, chats with file exchange, games
with object exchange, etc. Developers may think sending these blobs as
messages on an unordered channel would work without HOL blocking. But they
would be wrong since the current NDATA spec actually blocks, effectively
behaving like an ordered channel.

Once they debug this, they will rewrite the app to either:
1) create a new channel for every blob, which is excessive overhead for
the app, browser and SCTP stack (but NDATA does at least enable this
solution), or
2) fragment blobs in the app, which adds (some but less) overhead for the
app (and defeats NDATA).

These are the only ways to get unordered, non-blocking delivery. At least
NDATA makes the app hack 1) possible since channels don¹t block each
other. But it would be far more useful if unordered channels did not block
like ordered ones.

More inline.

Cheers,
Mo

On 10/30/14, 2:53 PM, Michael Tuexen <[email-masked]>
wrote:
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a
different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will block
other
   messages sent on the same data channel. Since it is an ordered channel,
this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small
one after
   that, there is no statement made in which these messages would be
delivered.
   Are you focussing on this and do you want to require some sort of
reordering?

Mo: Agreed on 1 and 2, with the admittedly minor caveat mentioned earlier
on 2 about blocking sender transmission vs. receiver delivery to app. For
3, which is indeed my focus, agreed the W3C spec makes no statement about
order (since the channel is unordered!), but the NDATA spec actually does
mandate HOL order for messages>MTU, which is counter to the whole point of
an unordered channel. A developer must override defaults to get an
unordered channel, presumably to get faster, non-blocking delivery for the
individual messages. Otherwise, what is the point of unordered channels if
they block just like ordered ones?

On 10/30/14, 5:55 PM, Michael Tuexen <[email-masked]>
wrote:

Mo: The point of unordered channels is to send and receive everything
whenever it becomes available. The transport does not need to worry about
providing any specific ordering, but it is not expected to block based on
internal ordering rules.