Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07

[Michael Tuexen <[e-mail]>]

On 23 Feb 2014, at 00:20, Paul Kyzivat <[e-mail]> wrote:

> (Catching up before the meeting)
> Here are some comments on the latest version. There don't necessarily relate to recent changes. Rather they come from my perspective trying to use this for CLUE, whether using a webrtc endpoint or not.
> 
> * Section 5:
> 
> This section 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.  The PPID is used to distinguish
>   UTF-8 encoded user data and binary encoded userdata.  The Data
>   Channel Establishment Protocol defined in
>   [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be
>   distinguished from user data.
> 
> The language has proved extremely confusing to several people who haven't followed the development and discussion of this from the beginning. It is because of the extreme ambiguity in the use of "protocol". While I guess we can't rename PPID, the other language could be clarified.
> 
> The problem is that we have SCTP protocol, "WebRTC Data Channel Establishment Protocol", and within the DATA_CHANNEL_OPEN message of the WebRTC Data Channel Establishment Protocol we have a "Protocol" field.
> 
> We also have layering of protocols and implementations. So it isn't clear above who "sender" and "receiver" above apply to. (Could be code that is calling the SCTP stack, or code that is calling the "data channel stack", or the browser, or a javascript application on top of browser.
> 
> IIUC, javascript users don't have any visibility to the PPID. But others implementing data channels may.
> 
> How about:
> 
>   Each SCTP user message contains a so called Payload Protocol
>   Identifier (PPID) that is passed to SCTP by the data channel layer
>   and sent to its peer.  This value is used to multiplex WebRTC Data
>   Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb-
>   data-protocol]) with messages containing user data on a data
>   channel. The PPID is also used to distinguish UTF-8 encoded user
>   data and binary encoded user data.
The above text has changed in the meantime due to comments. It currently reads:

<t>Each SCTP user message contains a Payload Protocol Identifier (PPID)
that is passed to SCTP by its upper layer on the sending side and
provided to its upper layer on the receiving side.
The PPID can be used to multiplex/demultiplex multiple upper layers over
a single SCTP association.
In the WebRTP context, the PPID is used to distinguish between
UTF-8 encoded user data,
binary encoded userdata and
the Data Channel Establishment Protocol defined in
<xref target='I-D.ietf-rtcweb-data-protocol'/>.
Please note that the PPID is not accessible via the Javascript API.</t>

Does this address your issues?
> 
> Also in this section is Figure 2 that shows layering. I'm unclear if "WEBRTC DATA" in intended to include rtcweb-data-protocol or not. That is defined in a separate draft, is mandatory to support but optional to use. So it could go either way. Might be good to clarify:
> 
> 
>                 +---------+
>                 |CHANNEL  |
>                 |PROTOCOL |
>                 +---------+
>                 |DATA     |
>                 |CHANNEL  |
>                 +---------+
>                 | SCTP    |
>   +-----------------------+
>   | STUN | SRTP | DTLS    |
>   +-----------------------+
>   |         ICE           |
>   +-----------------------+
>   | UDP1 | UDP2 | ...     |
>   +-----------------------+
Hmm. What about using
              +------+------+------+
              | DCEP | UTF-8|Binary|
              |      | data | data |
              +------+------+------+
              |        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|         ICE                      |
+----------------------------------+
| UDP1 | UDP2 | ...                |
+----------------------------------+

which also makes clear how the PPID is used to multiplex/demultiplex the different
upper layers?
> 
> * Section 6.5
> 
> This section contains:
> 
>   Data channels can be opened by using internal or external
>   negotiation.  The details are out of scope of this document.
> 
>   A simple protocol for internal negotiation is specified in
>   [I-D.ietf-rtcweb-data-protocol] and MUST be supported.
> 
> But internal and external negotiation are not defined in this document.
> 
> I *thought* that internal negotiation was by definition negotiation by use of rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 thinks so too, but calls it "in-band negotiation".)
We can use in-band and out-of-band negotiation
> 
> There should be a good definition of these terms, or reference to one. And more discussion if there can be other kinds of internal negotiation. (If so, how would one be chosen?)
Up to now, there is no other way.... Would you prefer that?
> 
> * Section 6.6:
> 
> Say:
> 
>   All data sent on a Channel in both directions MUST be sent over the
>   underlying stream using the reliability defined when the Channel was
>   opened unless the options are changed, or per-message options are
>   specified by a higher level.
> 
> Is the recipient to consider it an error if messages are received with options different from those defined for the channel?
Please note that the receiver could double the the ordering. The receiver could also
detect that messages have been abandoned on ordered streams, but not on unordered.
For successfully delivered messages, the receiver can not detect if the message was
sent reliably or not. There is no explicit way for the receiver to verify the PR SCTP policy
or the corresponding value. So I would vote for ignoring...
> 
> Also, is it an error if messages are received with a PPID that isn't specified in Section 8? (And what about PPID 50?)
> 
> How are such channel errors to be treated?
Reset the channel? Do we want to specify that?
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>