Re: Minimizing the protocol (Re: Data API)

On 2/29/2012 6:26 PM, Cullen Jennings wrote:
> I'd rather see it done in SDP as you were proposing - otherwise we end up reinventing the whole thing for no good reasons. And I think the SDP can associated the label with the correct SCTP channel. It will be trivial and not require any code that we did not have to already write for the RTP.

Well, I think we have good reasons to avoid going through the 
SDP/renegotiation process for every dataChannel object.

A primary issue is performance: the latency of channel setup through SDP 
is going to be significant.  A lot of cycles to do all the signaling and 
through whatever extra network and relaying latency the trip through the 
signaling server entails, parsing the SDP and deciding that no, all 
that's happening is adding a dataChannel, no need to modify any media 
streams, passing back the SDP via the server, parsing the response and 
deciding no, nothing changed in the response except accepting the 
dataChannel, and then, after all that, you need to send something on the 
SCTP stream to tell the answerer that the dataChannel is open (you might 
not need this if you decide the answerer can send on the dataChannel as 
soon as it sends the SDP response; but the offerer in theory shouldn't 
send until it gets the SDP response, so it would be kinda half-open).

That's a LOT of processing to do something very, very simple.  And 
honestly, it will require (much) more coding to handle it through SDP 
than to implement the tiny setup messages I pseudo-coded.

And the latency will be significant - I posited some examples in rtcweb 
where we're transferring a large number of files while chatting 
(synchronizing a directory, for example, or sharing a photo album - even 
proxy-browsing through the other end of the dataChannel connection; a 
potential no-media-streams usage of WebRTC).  These would be negatively 
affected by the channel open latency, or  force the application 
developer to implement their own channel protocol on top of a single 
WebRTC stream.

>
>
> On Feb 29, 2012, at 4:15 PM, Justin Uberti wrote:
>
>> Media stream labels are currently signaled through SDP attributes on media sources. I proposed a similar approach for data, to be consistent in how we handle media and data streams, but nobody really liked that idea that much; the thinking was that we could exchange the needed meta-info within the SCTP protocol instead of having to do it out-of-band using SDP.
>>
>> On Wed, Feb 29, 2012 at 4:14 PM, Cullen Jennings<fluffy@cisco.com>  wrote:
>>
>> I think we are going about this the wrong way. Lets sort out how labels work with media tracks then ask why if data channels would be any different. I think that this is going to turn out to be a non issue.
>>
>>
>> On Feb 28, 2012, at 4:28 PM, Randell Jesup wrote:
>>
>>> On 2/28/2012 4:18 PM, Harald Alvestrand wrote:
>>>> On 02/28/2012 06:36 PM, Randell Jesup wrote:
>>> [SNIP]
>>>>> Sorry.
>>>> argh. was fun while it lasted :-)
>>>> second suggestion is to have the first message contain the label and
>>>> flags.....
>>> Yup.  My rough plan was:
>>>
>>> First message on a stream (or first after a reset of the stream):
>>> (pseudo-structure)
>>> {
>>>     CHANNEL_OPEN,
>>>     flags, // reliable, unreliable, out-of-order, partially-reliable (and type), etc
>>>     pr_value,  // partially-reliable
>>>     DOMString label,
>>> }
>>>
>>> and response:
>>> {
>>>     CHANNEL_OPENED,
>>>     forward_stream_id, // optional
>>> }
>>>
>>> This assumes we can avoid stream number glare by using an even/odd differentiation.  If we can't or don't want to, we can include in the response the forward channel it's responding to (it would come in on the reverse channel for that bidirectional pair).  This allows us to avoid stream ID glare by never requiring the bidirectional pair have the same stream number.
>>>
>>> --
>>> Randell Jesup
>>> randell-ietf@jesup.org
>>>
>>
>>
>
>


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 1 March 2012 00:48:28 UTC