Subject: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 11:23:36 +0000

Hi,

This is related to the e-mail Paul sent yesterday (Data Channel question: correlating streams with channels).

Section 5 of draft-ietf-rtcweb-data-channel-06 says:

"Each SCTP user message contains a so called Payload Protocol
                Identifier (PPID) that is passed to SCTP by its upper layer and sent
                to its peer.  This value can be used to multiplex multiple protocols
                over a single SCTP association.  The sender provides for each
                protocol a specific PPID and the receiver can demultiplex the
                messages based on the received PPID."

Now, when I look at the IANA registration page for PPID values, most seem to be associated with specific protocols.

However, if I e.g. use PPID values 51-54 (as rtcweb applications will do) they don't say anything about the protocol. They refer to an encoding format, and multiple protocols may have the same format.

I would assume that the SCTP stream id would have to be used to multiplex protocols.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 5 Feb 2014 10:39:53 -0800

The PPID isn't exposed to the application.  It's just used to
distinguish text/binary/control.    If an application uses different
data channels with different protocols, it should use the SID to
distinguish between them, not the PPID.  In fact, even if it wanted to
use the PPID, it wouldn't be able to.

On Wed, Feb 5, 2014 at 3:23 AM, Christer Holmberg
<[email-masked]> wrote:
> “Each SCTP user message contains a so called Payload Protocol
>
>                 messages based on the received PPID.”
>
>
>
> However, if I e.g. use PPID values 51-54 (as rtcweb applications will do)
> they don’t say anything about the protocol. They refer to an encoding
> format, and multiple protocols may have the same format.
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 20:40:31 +0000

> use the PPID, it wouldn't be able to.
[Raju] PPID is also used by browsers (and other webrtc implementors like native clients) to fragment user given large data into smaller fragments (via "XYZ partial", "XYZ last" PPIDs) to avoid monopolizing the SCTP link for a single data channel's data.
See http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6 for more details.

-Raju

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 5 Feb 2014 13:09:39 -0800

> See http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6 for more details.

I believe that Firefox is the browser that does that.  At the last
IETF, I think we agreed that it's a temporary fix at best while we
wait until this problem is solved at the SCTP layer and not above it.

I'm not aware of any native clients that use this technique, unless
there are native clients that use Firefox's code.   Perhaps there are;
 I just don't know of any.

In any case, it's not part of the standard, and I think the plan is
that it won't be needed long-term.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 5 Feb 2014 22:11:48 +0100

> that it won't be needed long-term.
As discussed in the last IETF meeting, this PPID based fragmentation and reassembly
will be removed from the ID.

Best regards
Michael

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 21:32:46 +0000

> > wait until this problem is solved at the SCTP layer and not above it.
[Raju] Using NDATA I believe.

> will be removed from the ID.
[Raju] Can I then assume the reason for such removal is the availability of NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) sooner than later, which will make such PPID based fragmentation/reassembly immediately obsolete?

[Raju] -Raju

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 5 Feb 2014 22:47:36 +0100

> [Raju] Can I then assume the reason for such removal is the availability of NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03) sooner than later, which will make such PPID based f…
Right. The point was not to have two solutions, but use one.

Best regards
Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 16:59:51 -0500

Will NDATA support be required for rtcweb?

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 22:34:20 +0000

> > [Raju] Can I then assume the reason for such removal is the availability
> of NDATA (http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ndata-03)
> sooner than later, which will make such PPID based fragmentation/reassembly
> immediately obsolete?
[Raju] That makes perfect sense and NDATA is a better solution too! That also pushes browser vendors to support NDATA sooner than later.

-Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 22:35:54 +0000

> Will NDATA support be required for rtcweb?
[Raju] Yes. It is mentioned in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#page-3 which says the following:

   The SCTP base protocol specified in [RFC4960] does not support the
   interleaving of user messages.  Therefore sending a large user
   message can monopolize the SCTP association.  To overcome this
   limitation, [I-D.stewart-tsvwg-sctp-ndata]  defines an extension to
   support message interleaving.  Once such an extension is available, 
   it SHOULD be used.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 18:03:35 -0500

>     support message interleaving.  Once such an extension is available,

I guess that begs the question of what "Once such an extension is 
available" means, and what "it SHOULD be used" means. :-(

"available" could mean:

- once it is defined in a published RFC
- once it is defined in a WG draft or RFC
- once it is defined in an individual draft
   (e.g., draft-stewart-tsvwg-sctp-ndata-03)
- once it it is implemented in the browser you are using

"SHOULD be used" could apply to:
- browser implementers
- application implementers

And then there is the question of what "SHOULD" means. Specifically, 
what are the conditions where it would be acceptable to *not* follow this?

I *hope* this is intended to mean that browser implementers MUST 
*implement* it, and *use* it in their implementation of DataChannel once 
draft-stewart-tsvwg-sctp-ndata becomes an RFC. And SHOULD do so now 
based on draft-stewart-tsvwg-sctp-ndata-03.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 5 Feb 2014 23:33:12 +0000

>    (e.g., draft-stewart-tsvwg-sctp-ndata-03)
[Raju] I believe this is the case.
> - once it it is implemented in the browser you are using
[Raju] Browser implementations probably be more proactive in adapting this draft similar to number of other drafts that are being adapted in individual draft state.
I think this is one way browsers can differentiate themselves from others.
So, in my opinion, the "SHOULD" below probably ok and does not have to be a "MUST" as this NDATA is not a MUST have to deliver data channel requirements. If it has to be a "MUST" then I believe it has to be part of the requirement section 4 of http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-4 and list it as "MUST".

> based on draft-stewart-tsvwg-sctp-ndata-03.
[Raju] I am not sure if this NDATA is a deal breaker for webrtc 1.0?! Some implementations may support while others not as NDATA is negotiated during association setup; if one end does not support then it is disabled.

If you don't have NDATA then one data channel stream may monopolize the SCTP link and could affect scenarios like:
- You sent 1GB file using data channel stream 0 (all at once without using something like MSRP).
- Then immediately, you send a small "Hi, some important stuff!" chat message using data channel stream 1.
Without NDATA, the other end will receive the text msg ONLY AFTER receiving the 1GB file!! With NDATA chat msg gets equal share of the SCTP link and gets delivered much sooner.
You can apply this to even more sensitive gaming apps.

-Raju

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 6 Feb 2014 09:08:36 +0100

> [Raju] I believe this is the case.
draft-stewart-tsvwg-sctp-ndata has been adopted as a WG item in the TSVWG. We need
to update and resubmit it.
> Without NDATA, the other end will receive the text msg ONLY AFTER receiving the 1GB file!! With NDATA chat msg gets equal share of the SCTP link and gets delivered much sooner.
If NDATA is not supported, the message size is limited to avoid the monopolization. This limit
will be signalled through SDP.

Best regards
Michael

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 08:38:45 +0000

Hi,

> If NDATA is not supported, the message size is limited to avoid the monopolization. This limit will be signalled through SDP.

What do you mean by "signaled through SDP"?

Will the browser inform the JS app, using SDP, if the local and/or remote peer doesn't support NDATA?

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 6 Feb 2014 09:52:24 +0100

> Will the browser inform the JS app, using SDP, if the local and/or remote peer doesn't support NDATA?
What will be signalled in SDP is the maximum message size the end-point can handle. This is needed
anyway... If you don't support NDATA, you can signal a smaller value of, let's say 16KB or so.

NDATA is negotiated via the SCTP setup and there is no need for another signalling channel.

After the association is up, both sides know if NDATA is supported and, if I remember correctly,
there is a JS way of making message size limits available to the application. So you can
limit the message size if NDATA is not supported by both peers. So that is the plan:
* If NDATA is supported by both peers, message size are only limited by reassembly
  memory and any limit is signalled via SDP. The corresponding support will be in the
  next revision of the SDP ID.
* If NDATA is not supported by both peers, a message size limit applies to avoid monopolisation.

Best regards
Michael

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 12:08:41 +0000

>So you can

[Raju] The key is "next revision of the SDP ID". It is understood that NDATA support indication is only avilable after both the peers talk. But then, the initial message sizes were already conveyed (to make them talk). Now, if the new message size per "no NDATA support"/"NDATA support" is lower/higher then another ound of end-to-end signaling is needed to update the peers. Not optimal, but I do not see any other better way other than "starting conservatively with lower values initially assuming no NDATA support; later when NDATA support becomes widespread default values can be higher".

Best Regards
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 11:23:01 -0500

> * If NDATA is not supported by both peers, a message size limit applies to avoid monopolisation.

I assume that in the RFC this will just be a MUST NOT. Will that apply 
to the SCTP implementation? Or to the SCTP user?

(In a practical sense, will this be implemented in the SCTP stack, in 
the DataChannel "stack", in the browser, or in javascript?)

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 20:15:16 +0000

> the DataChannel "stack", in the browser, or in javascript?)

[Raju] It has to be done exclusively by the application (Javascript for browser or some other language for native apps).
This is because per recent comments the browser/data-channel level fragmentation/reassembly, based on PPID, will be removed from data channel core spec.

-Raju

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Feb 2014 22:40:35 -0800

The browser will enforce the message limit to ensure predictable behavior.

On Thu, Feb 6, 2014 at 12:15 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

> > > * If NDATA is not supported by both peers, a message size limit
> applies to
> > avoid monopolisation.
> >
> [Raju] It has to be done exclusively by the application (Javascript for
> browser or some other language for native apps).
> This is because per recent comments the browser/data-channel level
> fragmentation/reassembly, based on PPID, will be removed from data channel
> core spec.
>
> -Raju