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

[Michael Thornburgh <[e-mail]>]

in using RTMFP we recognize two different bidirectional channel modes:

  1) one (or more) return/response flows to an initial flow from one end

  2) truly symmetric bidirectional peer-to-peer channels

for (1), we use RTMFP's "Return Flow Association" facility (draft-thornburgh-adobe-rtmfp-04 sections 2.3.11.1.2, 3.6.1.1, 3.6.2.1, 3.6.3.1) to signal unambiguously at the transport layer when a new flow is in return/response to one from the other end.  associations can only be made to open flows.  unlike SCTP streams, RTMFP flows can be opened and closed at any time in a session.

for (2), we place a channel identifier marking in the flow metadata or initial message (or portions thereof in both places) of the flows from each end. the application makes the bidirectional association using these identifier markings.  there's no glare problem here since bidirectional communication is desired: if one end is opening but the other isn't, then the receiving end opens its half-connection in response (or rejects the incoming half-connection if it's not wanted); if both ends open their half-connections simultaneously, then you're done (on receipt of the incoming half-connection, you see that you already have the outgoing side open).  also in this case we typically send an application-layer ack message of the other end's half-connection open to signal the channel is fully bidirectional.

in both cases, this all happens end-to-end.  unidirectional flows are open immediately and data can be sent on them right away (if rejected by the other end, the sender will receive an exception).

unidirectional flows with return/response association allows you to build arbitrarily complex trees of flows.  we have found this lends itself to cleanly and naturally modeling the kinds of P2P communication we do in Flash Player, especially in our P2P overlay/mesh modes (like application-layer multicast).

-michael thornburgh


> From: [e-mail] [mailto:[e-mail]] On Behalf Of Matthew Kaufman (SKYPE) [[e-mail]]
> Sent: Friday, February 15, 2013 1:56 PM
> 
> 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)
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)
> 
> On Feb 15, 2013, at 1:16 PM, "Martin Thomson" <[e-mail]> wrote:
> 
> > On 15 February 2013 12:55, Michael Tuexen
> > <[e-mail]> wrote:
> >> I think I understand what you are proposing. But what happens, if
> >> both sides at about the same time open want to open a data channel.
> >> For both sides outgoing stream X is free, so they use this. So the
> >> endpoints end up with one data channel instead of two.
> >
> > Actually, I'd go further than that.  I'd require that browser
> > implement the same algorithm for selecting the stream to use.  That
> > implies that in all cases other than the rarest race conditions, you
> > get the same data channel.