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

[Salvatore Loreto <[e-mail]>]

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


-- 
Salvatore Loreto, PhD
www.sloreto.com