Subject: Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 4 Mar 2013 13:27:01 +0000

Thanks Randell for you review. My replies inline. 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Randell Jesup
> Envoyé : mardi 19 février 2013 07:49
> À : [email-masked]
> Objet : Re: [rtcweb] TR : New Version Notification for 
> draft-marcon-rtcweb-data-channel-management-00.txt
> 
> On 2/18/2013 7:07 PM, MARCON, JEROME (JEROME) wrote:
> > Hi,
> >
> > I have submitted a draft proposing a new way of setting up 
> data channels, based on the concept of data channel 
> configurations. It uses a lightweight SDP signaling coupled 
> with a lightweight in-band signaling (not an in-band 
> protocol). I think it can handle efficiently the most 
> demanding setup scenarios. The proposal is besides designed 
> with the intent to not impact on current browser API.
> 
> Thanks.  Still reading, but an initial comment:
> 
> "Whenever the application creates a new data channel, the 
> browser internally checks if the passed set of parameters 
> strictly matches an existing configuration, and if not 
> generates a new configuration identifier for this set. In the 
> latter case only does the browser trigger the application for 
> an SDP renegotiation."
> 
> Wouldn't this occur on almost every channel because of label 
> values?  Or are you assuming applications won't actually use labels?

In this first version of the proposal, the use of labels is still undefined, but (for the sale of scalability) it would for now remain a local data channel property not transmitted to the peer (should this local property be useful to something).

I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent decision. But then assuming the offer is for opening 100 data channels for file transfer (each channel with a distinct label), would the answerer's consent be asked 100 times (once per distinct label) ? Probably asking once "do you agree on some file transfers" is enough (and better). And the 'file transfer' information is carried by the subprotocol property, not the label.     

> 
> "For each data channel configuration in the offer that is 
> accepted by the answerer, the answerer echoes in the answer 
> the configurations supported and accepted. Once the offerer 
> receives the answer and (in case of an initial offer) the 
> SCTP initialization is complete, each data channel locally 
> created using one of the accepted configurations is signaled 
> to the application as open for transmission."
> 
> There's a bunch of API to surface here in order to support 
> O/A ("for each ... that is accepted by the answerer...").
> 
> "By convention, the inbound and outbound streams of a data 
> channel have the same SCTP stream number. This stream number 
> is selected by the first endpoint sending a user message on 
> this channel. Till this happens, an open data channel has no 
> assigned stream number."
> 
> How do you handle glare? (i.e. both sides start to send on 
> stream 5 at the same time)
> 
There are two methods proposed in section 6.5. You seem to be supportive of the 2nd method (even/odd stream number ownership convention).

> "Data channel messages are sent as SCTP user messages, 
> preceded in the DATA chunk User Data field by two bytes 
> specifying data channel configuration identifier as well as 
> the message data framing type (textual or binary)."
> 
> Aha.  So you've moved this into a true inband protocol with 
> data framing.  The current draft sends data messages with no 
> added framing required.

Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackward to reserve a PPID for something like "plain transmission of any binary data or UTF-8 stream". It seemed to me that each PPID today registered with IANA is identifying a true self-contained protocol. 

> 
> --
> Randell Jesup
> [email-masked]
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 6 Mar 2013 09:48:57 +0100

Hi Jerome,

thanks for the draft.
some initial comments

1)

1.  Introduction

    [I-D.ietf-rtcweb-data-channel] provides use cases and requirements
    for the definition of RTCWeb data channels, and outlines how the
    Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated
    within Datagram Transport Layer Security (DTLS) [RFC6347] can be used
    for this purpose.  While some of these requirements easily map to
    existing capabilities of the SCTP protocol and extensions (e.g.
    application messages can be carried as SCTP user messages), SCTP and
    existing SCTP extensions do not natively support the following
    requirements:

    o  data channel bidirectionality (this can be achieved by pairing one
       SCTP outbound stream and one SCTP inbound stream)

    o  data channel priority

    o  partial reliability of delivery, based on a maximum number of
       retransmissions

    o  general data channel setup

here the problem for the 1 and 4 bullets is that SCTP does not have the 
concept of data channel but only of stream.

About bullet 3, you may want to read the 
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-00
that propose how to define it.

About bullet 2, data channel priority, this is an important one that 
should be discussed and defined.
However I haven't found anything in your proposal about it.

2) Data Channel configuration
Sorry but it is not clear to me what how you use 
DataChannel-configuration...
i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, 
or we can have a 1:n relationship

if I understood you correctly in

6.2.  Opening a data channel out-of-band

...

       Note: for each new configuration, the offerer expectedly creates
       one data channel or more, whereas the answerer creates one data
       channel only.  How the final data channel pairing (and SCTP stream
       number assignment) is resolved is further explained in this
       document.

...

so in out of band mode, only one DataChannel will be created per 
DataChannel-configuration.
i.e. there is no way to create more DataChannels with the same 
DataChannel-configuration out-bound.
Isn't it? is so why? I don't get the advantage for this limitation

one of the reason people are asking for out-of-bound, is to give the 
possibility to "disclosure" what kind
of traffic (and how much) is going on between two WebRTC clients (i.e. 
browser).

However, it seems that you make then possible to open more DataChannels 
with the same DataChannel-configuration
in-band.

6.3.  Opening a data channel in-band

    Each user message sent in a data channel includes the identifier of
    the configuration which this data channel is bound to.  This
    signaling allows to enable or speed up the opening of new data
    channels in-band:

3) Framing

an inband protocol with data framing is unnecessary and a useless 
complication for WebRTC DataChannel.
That is why the 
http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 has no 
added framing required.

Please note that from a protocol point of view DataChannel is different 
from WebSocket.

In WebSocket it has been necessary to add a framing (and we tried to 
design a minimal one, eve if I am not sure we have succeeded in that),
mainly because we need to make the protocol frame-based where the pure 
TCP is stream-based.
You do not need to do that with SCTP, as it already provides:

        sequenced delivery of user messages within multiple streams, with
        an option for order-of-arrival delivery of individual user
        messages,

/Salvatore

On 2/19/13 1:07 AM, MARCON, JEROME (JEROME) wrote:
> Hi,
>
> I have submitted a draft proposing a new way of setting up data channels, based on the concept of data channel configurations. It uses a lightweight SDP signaling coupled with a lightweight in-band signaling (not an in-band protocol). I think it can handle efficiently the most demanding setup scenarios. The proposal is besides designed with the intent to not impact on current browser API.
>
> This is a first draft, thanks for your suggestions of improvements.
>
> Jerome
>
> ________________________________________
> De : [email-masked] [[email-masked]]
> Date d'envoi : mardi 19 février 2013 00:30
> À : MARCON, JEROME (JEROME)
> Objet : New Version Notification for    draft-marcon-rtcweb-data-channel-management-00.txt
>
> A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt
> has been successfully submitted by Jerome Marcon and posted to the
> IETF repository.
>
> Filename:        draft-marcon-rtcweb-data-channel-management
> Revision:        00
> Title:           RTCWeb data channel management
> Creation date:   2013-02-19
> Group:           Individual Submission
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-marcon-rtcweb-data-channel-management-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-marcon-rtcweb-data-channel-management
> Htmlized:        http://tools.ietf.org/html/draft-marcon-rtcweb-data-channel-management-00
>
>
> Abstract:
>     The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>     charged to provide protocols to support direct interactive rich
>     communication using audio, video, and data between two peers' web-
>     browsers.  For the support of data communication, the RTCWeb working
>     group has in particular defined the concept of bi-directional data
>     channels over SCTP.  How to transport application messages on these
>     data channels seems straightforward (i.e. they can be carried as SCTP
>     user messages), however it is yet to be decided how to establish and
>     manage these data channels.  This document specifies a method for
>     this, which relies first on a lightweight and scalable out-of-band
>     negotiation of data channel configurations (within the SDP offer/
>     answer exchange) and second on the signaling of the configuration in
>     use in the SCTP user message itself.  Once these configurations are
>     negotiated, further creations of data channels can occur purely in-
>     band by simply sending user messages, which avoids to define a new
>     in-band data channel protocol.
>
>
>
>
> The IETF Secretariat

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Randell Jesup <[email-masked]>
Date: Thu, 07 Mar 2013 09:49:59 -0500

> I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent…

The labels are for the application to differentiate between data 
channels that are using the same protocol.  For example, in a 
conference-with-central-mixer case, you might have a data channel to the 
mixer for each private conversation with another participant, plus one 
(or more) shared chats.  Each would be the same protocol, but have 
different labels.

Basically, they're there for the application to do something with, if it 
chooses.  It can totally ignore them if it wishes.  I'll note that RTFMP 
has a similar (though binary) concept.   They're a tool, and are 
particularly useful in cases where the data on the channel is an 
already-defined protocol as opposed to a new, application-specific 
protocol (where they could include the label inside their protocol).

These labels would need to be plumbed through to the recipient, not just 
local.

Another (I think already addressed) misunderstanding is that there's no 
requirement for user notification of data channels.  The reasoning is 
that a data channel is no different in user security/risk to existing 
mechanisms such as websockets, HTTPS connections - it just can go 
peer-to-peer and may have better latency charactistics (support for 
UDP-like transfers, etc).

> Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackw…

In-packet framing can be an annoyance for anything that's gatewaying an 
existing data stream into a channel.  It will work, but it means extra 
copying in both directions, and in some architectures/devices (SBCs, 
MCU's/conference servers) may complicate things, and some people have 
indicated the have (unspecified) usecases where they find gatewaying 
traffic directly onto these channels is desirable. Given there's a 
standard facility in SCTP that can be used for this (with a large 
address space), there seems to be little downside to using it.  I don't 
think we're in danger of running out of PPID's this millennium.  :-)

-- 
Randell Jesup
[email-masked]

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Sun, 10 Mar 2013 11:37:19 +0000

Hi Salvatore,

Thanks for your review. Some answers [JM1] in line.

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Salvatore Loreto
Envoyé : mercredi 6 mars 2013 09:49
À : [email-masked]
Objet : Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

Hi Jerome,

thanks for the draft.
some initial comments

1)

1.  Introduction

   o  data channel priority

here the problem for the 1 and 4 bullets is that SCTP does not have the concept of data channel but only of stream.
[JM1] The introduction basically says that some data channels requirements cannot be met using SCTP alone. It does not say that the document will address all these unfullfilled requirements

About bullet 3, you may want to read the http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-00
that propose how to define it.
[JM1] OK

About bullet 2, data channel priority, this is an important one that should be discussed and defined.
However I haven't found anything in your proposal about it.
[JM1] Yes, work to be done. I haven't found anything either in Randell's (yours) and Martin's proposal.

2) Data Channel configuration
Sorry but it is not clear to me what how you use DataChannel-configuration...
i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, or we can have a 1:n relationship
[JM1] Config -> 0..N Data Channels, and Data Channel -> 1 Config.

...

...

so in out of band mode, only one DataChannel will be created per DataChannel-configuration.
i.e. there is no way to create more DataChannels with the same DataChannel-configuration out-bound.
Isn't it? is so why? I don't get the advantage for this limitation
[JM1] For a new config declared in the offer, the answerer does not know how many data channels have been created on offerer's side (1 or more), i.e how many createDataChannel(withThisConfig) were called, as the SDP does not carry this number of channels. If the answerer's browser does nothing, then the answerer's app will not be aware of the offerer's data channels till the offerer sends messages on these. So:
- by creating one data channel of this config, the answerer's browser notifies the app that data sending is fine on this channel, and that other data channels of this config could be created inband later on
- but when I think of it now, this one data channel creation is unnecessary, because the app is unaware of configs anyway. It can at anytime create new data channels of any properties, and these will sometimes match an existing config (so no renegotiation), and sometimes not .
So this answerer's behavior should be removed I think. In any case, each endpoint app can create any number of data channels of any properties. The only noticeable difference noticeable to the app is that sometimes renegotiation will be triggered, sometimes not.

one of the reason people are asking for out-of-bound, is to give the possibility to "disclosure" what kind
of traffic (and how much) is going on between two WebRTC clients (i.e. browser).
[JM1] The kind of traffic is disclosed, not the amount

However, it seems that you make then possible to open more DataChannels with the same DataChannel-configuration
in-band.

3) Framing

an inband protocol with data framing is unnecessary and a useless complication for WebRTC DataChannel.
That is why the http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 has no added framing required.

Please note that from a protocol point of view DataChannel is different from WebSocket.

In WebSocket it has been necessary to add a framing (and we tried to design a minimal one, eve if I am not sure we have succeeded in that),
mainly because we need to make the protocol frame-based where the pure TCP is stream-based.
You do not need to do that with SCTP, as it already provides:

[JM1] one principle of the proposal is to not carry in-band any data channel properties, but instead the {SCTP stream number, Config ID} of the channel(s) to be opened. This draft 00 proposes to do so using some header in application message. I agree that despite the header is smaller (2 bytes) than the WebSocket (6 bytes or more), there are other concerns recalled by Randell. I have thought of alternatives since (still inline with the principle).

/Salvatore

Hi,

Jerome

De : [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]

Abstract:

The IETF Secretariat
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

--
Salvatore Loreto, PhD
www.sloreto.com<http://www.sloreto.com>