- From: Michael Tuexen <tuexen@fh-muenster.de>
- Date: Fri, 24 Feb 2012 13:20:25 +0100
- To: Randall Stewart <rrs@lakerest.net>
- Cc: Randell Jesup <randell-ietf@jesup.org>, public-webrtc@w3.org, Salvatore Loreto <salvatore.loreto@ericsson.com>
On Feb 24, 2012, at 12:33 PM, Randall Stewart wrote: > on thought.. > > On Feb 24, 2012, at 6:22 AM, Michael Tuexen wrote: > >> On Feb 23, 2012, at 11:18 PM, Randell Jesup wrote: >> >>> On 2/23/2012 3:35 PM, Michael Tuexen wrote: >>>> On Feb 23, 2012, at 3:44 PM, Randell Jesup wrote: >>>> >>>>> Correct; the idea discussed (at the Interim, and with Randall) was to either use stream 0 as a control channel, or to use PPID values to flag a message on a stream containing metadata such as an "open dataChannel" message, which would include information needed to open the reverse stream (and avoid 'glare' when both sides are opening streams at the same time), the label, and the channel options (so it has the same attributes in both directions). >>>> I almost always agree with Randy, but we have a different perspective when it comes the the PPID. >>>> Currently upper layers of SCTP register some values at IANA and this value is used, for example, >>>> by protocol analyzers like Wireshark to determine the upper layer protocol. If possible, >>>> I would like to keep it that way. >>> >>> We discussed registering a value or values with IANA for this. >> OK, great. Using some IANA registered values is fine with me. Thanks for the clarification. >>> >>>> So you want that one side creates a channel with an identifier which is a string. This is >>>> transported to the other side. Right? >>>> What should happen if both sides try to open a channel with the same identifier? Should >>>> this result in one channel? >>>> It seems that we need to messages which are exchanged... >>> >>> Right; this is a variation of the 'glare' case. (Two types of glare here: collision on names, and collision on stream IDs selected.) For "name glare", I'd just mark both sides as open and ready. You could also fail one of them (requires a message back indicating failure due to collision) and then give an ondatachannel message saying the other side created it, but then you have to decide somehow how to chose which one "wins". Easily doable, but gains you nothing over just telling both sides it's open (one place bidirectional helps you). >> OK. But we need some messages... >>> >>>> I also assume that you want to map channels to streams, but you can map multiple channels >>>> to one stream, right? >>> >>> Actually, I was going to map each channel to a stream in each direction (though they don't have to have the same stream number - again an artifact of glare). So once established, there's a 1-1-1 relationship of incoming stream, outgoing stream and data channel object, with no sharing. >> OK. Fine. I was not sure if you wanted it 1-1-1. Thanks for the clarification. >>> >>>> It looks like we need some rtcweb control message for opening and closing a channel. These >>>> would transfer the channel identifier. >>>> One would use a separate PPID for >>>> * the control messages >>>> * user messages containing a DOMString >>>> * user messages containing an ArrayBuffer >>>> * user messages containing an Blob >>> >>> We can use a PPID for identifying those object types, or we could layer that into the binary protocol. If the PPID space is large (and it is), I'm good with defining 4 PPID values, and we would define more if/as needed (and register them all with IANA). >> OK. >>> >>>> We need to make sure that messages sent on a channel don't arrive earlier than the open message... >>>> and that the close messages are the last one... >>> >>> Yes, I was going to specify "reliable in-order" for those. Also, Randall and I were talking about resetting a stream to indicate a close (though that opens a question about in-flight messages versus the reset). If we were unidirectional and didn't use labels (just stream IDs), we could probably use reset for indicating channel open, but I think there's enough consensus to ignore that. >> I'm not sure if it is better to >> * reuse the stream reset stuff to signal open/close of a channel (implicit way) >> * use some explicit messages (explicit) >> I tend to the explicit way since we need to communication the channel identifier anyway. >> >> The sequencing problem I see: >> * You transfer unordered user messages >> * You close the channel >> We need to make sure that the close channel message is not processed before all >> unordered user messages have been processed (at least if the user messages are >> sent reliable). > > At the SCTP level (not the app level), you cannot get a stream > reset processed until all the messages pending on the stream have > been ack'd … if I remember right ;-) Which would be an argument to use Stream Reset in addition to some control messages... Then the user still needs to process them all... There is no guarantee in which sequence the SCTP stack delivers them... We had this problem in DTLS... I was thinking about something for which the closing of one channel does not affect the the others... SenderDry would be an alternative, but it also affects the whole association. Best regards Michael > > R > >>> >>>>> Right. I was trying to indicate in my response that streams would (at open time) have attributes that specify reliable, unreliable, in/out of order, and for non-reliable a value to control retry/abandonment (exact semantics TBD but should map simply to the SCTP options). I mistakenly added them to the wrong dictionary. >>>> I could imagine that for some applications want to limit the number of retransmissions (most likely to 0) >>>> or want to limit the lifetime of the message. Both it supported by our userland stack. >>> >>> Exactly, but my suggestion was (for now) to limit those to be a channel attribute, instead of per-user-message. >> That is fine with me. >> >> Best regards >> Michael >>> >>> -- >>> Randell Jesup >>> randell-ietf@jesup.org >>> >>> >>> >> >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > >
Received on Friday, 24 February 2012 13:31:00 UTC