Re: [rtcweb] Data channel setup and signalling

Randell Jesup <randell-ietf@jesup.org> Tue, 15 November 2011 19:20 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE5621F899F for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 11:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.268
X-Spam-Level:
X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1ygm5Dx8erB for <rtcweb@ietfa.amsl.com>; Tue, 15 Nov 2011 11:20:12 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CA25821F899D for <rtcweb@ietf.org>; Tue, 15 Nov 2011 11:20:11 -0800 (PST)
Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RQOYF-0000QL-7d for rtcweb@ietf.org; Tue, 15 Nov 2011 13:20:11 -0600
Message-ID: <4EC2BB37.4060907@jesup.org>
Date: Tue, 15 Nov 2011 14:19:19 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4EC209EB.3080402@jesup.org> <4EC23013.1030302@alvestrand.no> <CAOJ7v-3wmciNyFrHMhZZTydAhcTpAxRj+U1sq11Ku6Ygwodg2Q@mail.gmail.com>
In-Reply-To: <CAOJ7v-3wmciNyFrHMhZZTydAhcTpAxRj+U1sq11Ku6Ygwodg2Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Data channel setup and signalling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2011 19:20:20 -0000

On 11/15/2011 9:05 AM, Justin Uberti wrote:
>
>
> On Tue, Nov 15, 2011 at 4:25 AM, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>
>     On 11/15/2011 02:42 PM, Randell Jesup wrote:
>
>         The signalling discussion and how it touched on data channels
>         got me thinking.
>
>         One open issue is how we define data channels, both in the
>         "internal" case (no interop) and the federated case (which may
>         have the same JS app or different ones at either end).
>
>         One solution is that all data channels are defined as m= lines.
>           They could be generic "m=data", or they could specify the data
>         to be passed in the m= line.  For "public" message structures
>         that might be used by different applications (an IM protocol,
>         for example), one would specify that in some manner in the media
>         description (perhaps via a MIME type).  This also implies that
>         any addition or removal (or change to) a data channel requires a
>         full replacement OFFER and ANSWER.  If we stick with the SDP
>         requirement about never removing m= lines, then the OFFER size
>         may become unbounded.
>
>     Just to add to the confusion:
>     If one instead keeps the (each?) SCTP connection as one m= line, one
>     could instead model the data channels as corresponding to SSRCs, and
>     reuse the codec declaration mechanisms from RTP m= lines to assign
>     specific data syntaxes to each SSRC....
>
>     this seems to me to be a model that adheres more closely to the RTP
>     model, but that doesn't mean it's a good fit to SCTP, or a good fit
>     to real applications' real requirements.

That's interesting... something like

    m=data 1234 webrtc/data 1 2 3 4
    a=rtpmap:1 SCTP/8000/1
    a=ftmp:1 reliable
    a=rtpmap:2 SCTP/8000/2
    a=fmtp:2 partially-reliable;time-limit=500
    a=rtpmap:3 SCTP/8000/3
    a=ftmp:3 reliable;stream
    a=rtpmap:4 SCTP/8000/4
    a=ftmp:4 unreliable;out-of-order

etc.  The /1, /2 paramter to rtpmap would be the SCTP data channel 
number (or the "payload" value could also be that).  Or, as you say, 
they could be SSRCs, but you need to pre-define what type of data 
channel they correspond to as per above.  Plus remember we don't have an 
SSRC on each datagram; it comes into a channel, and something needs to 
know it's coming and service the stream.

>         The other option is to have (some) data channels be separate
>         from media, in particular app-specific anonymous data channels.
>           There's no requirement for describing the channels if they're
>         private to the app, at least to the first approximation.  An app
>         could pre-define data channel 3 as a private message structure
>         for game map updates, so long as it knows its talking to itself.
>
>         This has advantages in setup time, especially if the data
>         channels are dynamic and invoked via another data channel, since
>         there doesn't have to be a full offer-answer including the media
>         channels.  You just need to make sure the two sides agree on the
>         data to be exchanged and that they listen before receiving data.
>           It has a minor advantage in reducing the amount of information
>         leakage to the server about the creation and types of streams
>         (and potentially significant metadata about them).
>
>
>         A use-case would be a background http proxy-server during chat.
>           If you have to re-OFFER for each data channel that comes and
>         goes to transfer a resource, it will both swamp the server and
>         be slow (due to the triangle signalling).  If instead the
>         application can open a single control data channel, and invoke
>         transfers over it, the application can efficiently transfer a
>         high number of URIs.  Are there other ways to do this without
>         re-OFFERing constantly?  yes.  But they generally involve
>         building protocols on top of an array of long-lasting generic
>         connections.
>
>         For example, the control data channel might pass messages
>         (directly browser-to-browser) like
>         {
>            id: 1,
>            command: "GET",
>            URI: "blah/foo/bar",
>            channel: 5,
>         }
>         with an answer:
>         {
>            id: 1,
>            result: "ok",
>            size: 1234,
>         }
>         followed by transfer of the URI on data channel 5.  (Note: in
>         this I'm assuming an API that lets the app open a specific data
>         channel of the peer connection.)
>
>         Now, this is contrived, though plausible.  You could pre-open a
>         bunch of idle data connections and then re-use them as needed.
>           The counter-argument is that one could write a
>         connection-server library that abstracts a bunch of pre-opened
>         data channels into an API for the app that works like I
>         described above, though it may require more housekeeping and
>         larger fixed resource usage.
>
>     This example in fact VERY closely resembling FTP..... make the
>     commands one-line instead of JSON blobs, and the responses into
>     numeric codes, and the resemblance is just about uncanny....

Yeah, that's not entirely unintentional.  Originally the example WAS 
effectively multi-channel FTP (background file transfer), but I thought 
this was more interesting.

>         So.....
>
>         Is it worthwhile to consider interfaces/APIs whereby an
>         application could directly open data channels with no re-OFFER
>         and implement a control protocol similar to the one I described?
>           Are there other use-cases for high-volume data channel
>         create/removal, or where data channel latency creation is
>         critical? (my usecase is a little contrived since I'm falling
>         asleep a the keyboard.)
>
>     I kind of like the idea of being able to open data channels with no
>     re-offer; we could pattern the API of new incoming data channels on
>     the handling of SSRCs that weren't mentioned at negotiation time
>     .... not that we've worked that out at the API level, last time we
>     discussed it, I think it was suggested that any new SSRC was
>     signalled as a new MediaStream...
>
>
> I'd prefer to have one way of doing things that's consistent, i.e. using
> re-OFFER for adding datastreams or SSRCs. This wouldn't have to be slow;
> if you already had a datastream, as you indicate in your example, the
> re-OFFER could occur over this path. Doing it this way would also allow
> metadata regarding the SSRC or datastream to be communicated to the
> other side prior to using the stream.

Well, we haven't talked directly about using a datastream to do 
re-OFFER.  Certainly possible, if we have a datastream defined for that 
(and since transport of the signalling is entirely up to the 
application, it could use a datastream for updated OFFER and ANSWERs). 
It is a bit chicken-and-egg like, but in practice that's not a problem 
if we're careful not to close the datastream used for this in the 
re-OFFER...

A big issue with re-offer on every data channel coming or going is that 
the overhead of offer-answer is significant (especially if we don't find 
a way to cull 'dead' m= lines in ROAP/SDP).  We probably need to make 
sure in any case that parts of the SDP that don't change never notice a 
re-OFFER/ANSWER however, not even to force an IDR or re-init a jitter 
buffer.

-- 
Randell Jesup
randell-ietf@jesup.org