Re: [rtcweb] Data Channel Negotiation and reopening of decisions

On Feb 14, 2013, at 11:34 PM, Martin Thomson wrote:

> I should probably collate responses.
> 
> On 14 February 2013 01:44, Randell Jesup <randell-ietf@jesup.org> wrote:
>>> None of what I suggest would change the API.
>> 
>> I think the no-negotiation proposal would require various API changes if you
>> work out the details.
> 
> Sure, some changes, but nothing that would prevent channels from being
> used interchangeably with websockets.  That is, once they are
> established.
> 
>> I understand the wish to reduce code.  (You do realize we're running over a
>> lightweight stack like SCTP over DTLS over ICE/TURN over UDP, right?  ;-)
> 
> Presumably you bought all those other parts of the stack.
> 
>> However, I'm not sure that you're actually reducing code by shifting to SDP
>> (I think you're just moving the code/complexity, as the existing structures
>> for negotiating m= lines can't be reused here I believe).  And I think the
>> SDP+no-negotiation-open proposal ends up with yet more complexity (and
>> importantly, more application (JS) complexity).
> 
> I was under the impression that the SDP code was already needed.  That
> was the premise behind making the suggestion - if we're not using SDP
> to negotiate channels ever, then I might be tempted to revise that.
> 
>> The least complex IMHO is the 0-RTT in-band option, though it's similar in
>> complexity to the current "pure" inband (without accelerated call-start
>> creation via SDP - i.e. 1.5RTT for all opens).
> 
> The least complex is to have the application just use channels with no
> in-band messages at all.  But we can't do that because we need to have
> messages tagged as being "binary" or "text" to further propagate the
> mistake that the websockets design made.
You could use the PPID of SCTP and would not need the in-band messages...

However, assuming datachannel are bidirectional, I really think we need some
sort of signaling to set them up to avoid collisions. The JS user should
have a clearly defined behavior. So I think the 1.5 RTT solution is the base.
The additional SDP solution is only an acceleration for providing initial
datachannels in 0-RTT. However, allowing the 0-RTT in-band option provides
the same speed-up and isn't restricted to the initial data channels.
So the purely in-band solution with the 0-RTT option seems to be the best
for me. But as Randell pointed out: We had this discussion already and I'm
not sure what we get if we open up it again. New arguments doesn't seem
to come up...

Best regards
Michael
> 
>> Partly my comments were aimed at all instances where we go back (and go back
>> again) with progress being elusive, not just this one issue.
> 
> Yeah, I understand the frustration.  I used to get frustrated with
> this sort of thing too.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 