Re: [rtcweb] Lower-overhead protocol variations

[Stefan Håkansson LK <[e-mail]>]

On 2013-02-25 13:28, Harald Alvestrand wrote:
> 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.

I think so too. For WebSockets, you get the close event (with a reason 
why it was closed [1]); the app has to establish a new one. The data 
channels should have the same behavior IMO.

[1] http://dev.w3.org/html5/websockets/#closeevent

>
>                     Harald
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb