Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <512DF818.2010302@ericsson.com>
Date: Wed, 27 Feb 2013 19:32:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <86DED275-D2FF-4839-9B77-18E205015D35@lurchi.franken.de>
References: <512540A3.3090008@jesup.org>
 <0DB30A45-97A6-4974-9CBB-BEE6691EFCE2@lurchi.franken.de>
 <51263522.1030206@jesup.org>
 <3FAF754D-8040-49FC-B0AD-F17BF705F62C@lurchi.franken.de>
 <512B58F2.3020408@alvestrand.no>
 <2594249F-FA21-4872-80E3-6F2EB7B87F85@lurchi.franken.de>
 <512BEAFE.1050700@alvestrand.no>
 <A4EB2CA5-BD1B-4833-A732-7E8514BBF2E4@lurchi.franken.de>
 <512DF818.2010302@ericsson.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Lower-overhead protocol variations
Precedence: list

On Feb 27, 2013, at 1:12 PM, Salvatore Loreto wrote:

> On 2/26/13 9:36 AM, Michael Tuexen wrote:
>> On Feb 25, 2013, at 11:51 PM, Harald Alvestrand wrote:
>>=20
>>> On 02/25/2013 04:22 PM, Michael Tuexen wrote:
>>>> On Feb 25, 2013, at 1:28 PM, Harald Alvestrand wrote:
>>>>=20
>>>>> On 02/21/2013 09:19 PM, Michael Tuexen wrote:
>>>>>> On Feb 21, 2013, at 3:54 PM, Randell Jesup wrote:
>>>>>>=20
>>>>>>> On 2/21/2013 8:03 AM, Michael Tuexen wrote:
>>>>>>>> On Feb 20, 2013, at 10:31 PM, Randell Jesup wrote:
>>>>>>>>=20
>>>>>>>>> This is a relevant thread to current discussions:
>>>>>>>>> =
http://www.w3.org/mid/D1737092-F63D-4821-B3FA-D425267E4F23@cisco.com
>>>>>>>>> and continued with subject change in
>>>>>>>>> http://www.w3.org/mid/4F4D6315.9000601@jesup.org
>>>>>>>>>=20
>>>>>>>>> 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?
>>>>>>>>=20
>>>>>>>> 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:
>>>>>=20
>>>>> 6.  The Setup and Connection Attributes and Association Management
>>>>>=20
>>>>>   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.
>>>>>=20
>>>>> The relevant table from section 4 of RFC 4145 is:
>>>>>=20
>>>>>           Offer      Answer
>>>>>            ________________
>>>>>            active     passive / holdconn
>>>>>            passive    active / holdconn
>>>>>            actpass    active / passive / holdconn
>>>>>            holdconn   holdconn
>>>>>=20
>>>>> 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".
>>>> OK. I was writing the statement based on how things are currently =
implemented
>>>> in Firefox. Both side are the active side...
>>>>=20
>>>> Thanks for the clarification.
>>> That confuses me ... do both sides send INIT (RFC 4960 section 5.1 =
step A)?
>> Yes...
>>> Collision is described in section 5.2.1 section B - I guess that if =
that's something that makes sense to provoke on a regular basis, "both =
active" can make sense.
>> Yes, SCTP handles INIT collisions. In API terms: Bots call connect() =
(using the 1to1 style API).
>> This is possible, since both sides know the port number of the peer.
> thanks for the clarification Michael.
>=20
> just to be clear before I do any changes in the The MMUSIC SCTP draft,
> is this something always true? (i.e. implementation independent)
No. It is how it is currently handled in Firefox. If i remember it =
correctly,
ekr preferred a symmetric solution. So he hasn't to figure out which =
side
is active and which side is passive. Could be related to the fact, the =
Firefox
currently doesn't use SDP for the data channels (if I remember it =
correctly).
>=20
> even if I haven't checked I am not sure it is true also for the "1 to =
many" model...
> and that make me cautious on doing any changes unless we do not =
restrict the scope of
> the draft to 1to1 style
INIT collision is also handled by 1-to-1 style sockets.

Best regards
Michael
>=20
> br
> /Salvatore
>=20
>=20
>>=20
>> Best regards
>> Michael
>>> draft-ietf-mmusic-sctp-sdp needs to be updated with this =
possibility.
>>>>> 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.
>>>>>=20
>>>>>                   Harald
>>>>>=20
>>>>>=20
>=20
>=20