Re: [rtcweb] Lower-overhead protocol variations

[Harald Alvestrand <[e-mail]>]

On 02/21/2013 09:19 PM, Michael Tuexen wrote:
> On Feb 21, 2013, at 3:54 PM, Randell Jesup wrote:
>
>> On 2/21/2013 8:03 AM, Michael Tuexen wrote:
>>> On Feb 20, 2013, at 10:31 PM, Randell Jesup wrote:
>>>
>>>> This is a relevant thread to current discussions:
>>>> http://www.w3.org/mid/[e-mail]
>>>> and continued with subject change in
>>>> http://www.w3.org/mid/[e-mail]
>>>>
>>>> I'm re-evaluating if the original decision against even/odd was required,
>>>> in order to see if we can collapse the current draft 0-RTT proposal
>>>> into a single declarative "open" message on a stream with no response or ack
>>>> required. Even/odd (perhaps based on a property of the SCTP association?)
>>>> would avoid the need for mismatched channel pairs, and thus avoid the need
>>>> for the response/ack and the need to send with the in-order bit.
>>> I'm not sure what you mean you even/odd?
>>>
>>> I guess you will send the "open" message reliable and ordered. OK.
>>> Are you proposing that there is no ACK sent back? What would happen
>>> if one side sends an "open" message indicating an unordered data channel,
>>> sends a user message on this channel and the user message is delivered
>>> first?
>> As you infer below, this would be one side uses even channels to initiate, the other uses odd (to avoid glare).
>> The reliability question is important; the simplest solution would be to buffer any data that arrives without an Open message until the Open message is received, and then deliver it.  There's no issue in the other direction, as once the open message is received the receiver can then send on that stream/channel with no restrictions. I assume there's some way to reliably choose roles for even/odd selection in SCTP?  If not, we can find other ways to do it (even SDP if we had to), though I think we could also key off the DTLS.
> Not sure we can choose based on SCTP. The port numbers can be the same and we have no addresses
> available. Maybe we can use the client/server identity from DTLS (the DTLS client uses even,
> the DTLS server uses odd).

The MMUSIC SCTP draft (draft-ietf-mmusic-sctp-sdp-03.txt) says:

6.  The Setup and Connection Attributes and Association Management

    The use of the 'setup' and 'connection' attributes in the context of
    an SCTP association is identical to the use of these attributes in
    the context of a TCP connection.  That is, SCTP endpoints MUST follow
    the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
    the use of the 'setup' and 'connection' attributes in offer/answer
    [RFC3264] exchanges.

The relevant table from section 4 of RFC 4145 is:

            Offer      Answer
             ________________
             active     passive / holdconn
             passive    active / holdconn
             actpass    active / passive / holdconn
             holdconn   holdconn

I think that based on RFC 4145, it would be reasonable to say that the 
party in the "active" role uses the even channels and the party in the 
"passive" role uses the odd channels, and that if the initiator uses 
"actpass", no channel assignment can be made until the answer comes back 
as either "active" or "passive".

This, of course, implies that channel numbers are reassigned from a 
blank slate if the connection goes down and is reestablished with new 
values for active and passive. Probably one should say that if the 
connection goes down, all channels go down too - that the data channel 
system doesn't attempt to layer yet another layer of reconnection on top 
of the already existing ones.

                    Harald