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

On Feb 16, 2013, at 6:15 PM, Randell Jesup wrote:

> On 2/16/2013 10:33 AM, Matthew Kaufman (SKYPE) wrote:
>> Can you describe the "simple protocol to realize bi-directional data channels by combining two uni-directional streams" without referring to any of what now appear to be unresolved issues?
> 
> Let me try to succinctly summarize the low-level protocol (details are in the draft).  This is the wireline protocol, which can support 0 RTT usage.  It's pretty darn simple as protocols go.
> 
> This assumes the association has been created.
> 
> 1) when one side wishes to open a channel with a given set of characteristics (label, IANA websockets-protocol, reliability options), it selects an unused outgoing stream X and sends Open on stream X.
> 
> 1a) the Channel is now open on the sender's side and can be used for send(); but note that until an OpenResponse is received, the in-order bit will be set on any data packets
> 
> 2) when an Open request is received (on any stream not already in-use), a reverse-direction outgoing stream Y is selected.  An OpenResponse(X) is sent on stream Y, and the application is notified a stream has been created.
> 
> 2a) the Channel is now open on the receiver's side and can be used for send(), but note that until an ACK is received, the in-order bit will be set on any data packets.
> 
> 3) when an OpenResponse(X) is received on an unused channel (Y), it's paired with X, and an ACK is sent on X.  The in-order bit is no longer forced on.
> 
> 4) when an ACK is received on a channel, the in-order bit will no longer be forced on when sending data.
> 
> 
> And that is basically it.
... already including the 0 RTT optimization.

Without it:
(a) Endpoint A selects one of its outgoing streams, sends an OpenRequest on it containing the label and reliability parameter.
(b) Endpoint B selects one if its outgoing streams, send an OpenResponse on it containing the incoming stream identifier on
    which the OpenRequest was received.
(c) Endpoint A sends an OpenAck.

(a) is used to "negotiate" the parameters of the data channel.
(b) is used to tie together the streams in both directions.

That is all. A simple three way handshake.
Randell's optimizations allow to send userdata right after (a).

Best regards
Michael
> 
>> On Feb 16, 2013, at 7:23 AM, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de> wrote:
>> 
>>>> None if this would be a problem if we weren't making the mistake of using SCTP, which itself made the mistake of doing full-duplex channels instead of unidirectional channels with optional one-to-one or even many-to-one associations (as RTMFP has, as an example)
>>> SCTP streams uni-directional. That is why we use a simple protocol to realize bi-directional
>>> data channels by combining two uni-directional streams.
>>> SCTP association, however, are point-to-point. The API (1-to-many style) allows sending
>>> a single messages (a single send() call) on all associations belonging to that socket.
>>> 
> 
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 