Re: [rtcweb] Lower-overhead protocol variations

Salvatore Loreto <salvatore.loreto@ericsson.com> Wed, 27 February 2013 12:12 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB70421F8549 for <rtcweb@ietfa.amsl.com>; Wed, 27 Feb 2013 04:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.169
X-Spam-Level:
X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWVCioQXm1vg for <rtcweb@ietfa.amsl.com>; Wed, 27 Feb 2013 04:12:13 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8F48E21F854D for <rtcweb@ietf.org>; Wed, 27 Feb 2013 04:12:12 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-13-512df81b0881
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 79.6E.19728.B18FD215; Wed, 27 Feb 2013 13:12:11 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 27 Feb 2013 13:12:11 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 960522AD9; Wed, 27 Feb 2013 14:12:10 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2B78954568; Wed, 27 Feb 2013 14:12:08 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6D8AA53365; Wed, 27 Feb 2013 14:12:07 +0200 (EET)
Message-ID: <512DF818.2010302@ericsson.com>
Date: Wed, 27 Feb 2013 14:12:08 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@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>
In-Reply-To: <A4EB2CA5-BD1B-4833-A732-7E8514BBF2E4@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvja70D91Ag5kLFC2O9XWxWVxsWsJo sfZfO7sDs8eVCVdYPZYs+cnksaFlB1MAcxSXTUpqTmZZapG+XQJXxvLXD5gKJmlWXN/6l62B 8ZpCFyMnh4SAicSPRRcZIWwxiQv31rN1MXJxCAmcZJT49Gc9E4SzgVHi+vkjjBDOLkaJi+eO MUM4axklent3Q/VsY5RoXdnCDDKMV0BbomXGF7DBLAKqEiem7mYCsdkEzCSeP9wCViMqkCzx 79ERRoh6QYmTM5+wgNgiAqYSB5fPA7OZBWwlnp55yQ5iCwtYSDzsOQJ102smiWWL7oMN5RRw ldhw5hIjTMOFOdehmuUltr+dwwzxnZrE1XObwGwhAS2J3rOdTBMYRWch2T0LSfssJO0LGJlX MbLnJmbmpJcbbWIERsTBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsbY0nUuyX+3rCtYtNL7xxQd3+p7PgqT9Fdks2dG7vc5tevmhg2xdefZ68+snb/u dE51Y02leEXKgetVbi4TEi4+Wnalfd6FCLvLTx/sM1/iZLBe4FXNCn+WJz2l4pP3XbhZ2VLS k824pvaK9EUOvv3p3JYPtK7uSSxS1oozcvL1mRW2WHrG8lwlluKMREMt5qLiRAD/5SD2VgIA AA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Lower-overhead protocol variations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 12:12:14 -0000

On 2/26/13 9:36 AM, Michael Tuexen wrote:
> On Feb 25, 2013, at 11:51 PM, Harald Alvestrand wrote:
>
>> On 02/25/2013 04:22 PM, Michael Tuexen wrote:
>>> On Feb 25, 2013, at 1:28 PM, 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/D1737092-F63D-4821-B3FA-D425267E4F23@cisco.com
>>>>>>>> and continued with subject change in
>>>>>>>> http://www.w3.org/mid/4F4D6315.9000601@jesup.org
>>>>>>>>
>>>>>>>> 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".
>>> OK. I was writing the statement based on how things are currently implemented
>>> in Firefox. Both side are the active side...
>>>
>>> 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.

just to be clear before I do any changes in the The MMUSIC SCTP draft,
is this something always true? (i.e. implementation independent)

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

br
/Salvatore


>
> 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.
>>>>
>>>>                    Harald
>>>>
>>>>