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

["MARCON, JEROME (JEROME)" <[e-mail]>]

Hi Salvatore,

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


________________________________
De : [e-mail] [mailto:[e-mail]] De la part de Salvatore Loreto
Envoyé : mercredi 6 mars 2013 09:49
À : [e-mail]
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

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


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


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,

[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



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 : [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>]
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
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb




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