Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 23 September 2011 10:48 UTC

Return-Path: <stefan.lk.hakansson@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 2833921F8BA7 for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 03:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.335
X-Spam-Level:
X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sJN5wPnNkbm for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 03:48:11 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 332A021F8A95 for <rtcweb@ietf.org>; Fri, 23 Sep 2011 03:48:11 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-de-4e7c6484baad
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.50.20773.4846C7E4; Fri, 23 Sep 2011 12:50:44 +0200 (CEST)
Received: from [150.132.141.36] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 12:50:44 +0200
Message-ID: <4E7C6483.8060106@ericsson.com>
Date: Fri, 23 Sep 2011 12:50:43 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com><092401cc749b$8fd64940$af82dbc0$@com><CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> <4E7B5A2F.8020102@ericss on.com> <4E7B6774.7040601@jesup.org> <4E7C3375.2070404@ericsson .com> <4E7C5269.8050100@alvestrand.no>
In-Reply-To: <4E7C5269.8050100@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
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: Fri, 23 Sep 2011 10:48:12 -0000

On 2011-09-23 11:33, Harald Alvestrand wrote:
> On 09/23/11 09:21, Magnus Westerlund wrote:
>> On 2011-09-22 18:51, Randell Jesup wrote:
>>> I wonder: could we create a default reliable data channel in all
>>> PeerConnections that's used (solely?) for a heartbeat/"consent freshness"?
>>> In that case, we get to define the heartbeat and can mandate enough entropy.
>>> (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.)
>>>
>> The short answer is Yes, you can. But the longer answer is that it might
>> imply limitations on what deployments are possible.
>>
>> First of all, this is only in reality practical when you only have a
>> single 5-tuple in use between the peers. If you don't multiplex all
>> flows on a single 5-tuple then you will need both consent and keep-alive
>> for each bi-directional flow the 5-tuple represents.
>>
>> Secondly, for any consent freshness / heartbeat you do need to transmit
>> regularly. And considering common NAT timers for UDP we do need to have
>> keep-alives no less often than every 15 seconds to try to ensure that
>> the very aggressive timers of 30 seconds don't disconnect the session.
>>
>> Thirdly one are using resources both in establishing this reliable data
>> channel, and then when using it for this function. Yes, you will spend
>> some resources on heartbeat in all cases. But you might have to do it
>> for multiple flow and then the reliable is an additional flow to
>> keep-alive if it isn't used for anything else.
> And fourthly, any spec that requires a heartbeat channel on the media
> path mandates a media path gateway in order to interoperate with
> non-RTCWEB devices.
>> So I am not thrilled of establishing an additional flow just for consent
>> freshness. In fact I am not thrilled by the PeerConnections default UDP
>> unreliable channel and believe the transports should be only enabled
>> upon demand from the application for such a transport.
> We're removing it from the API spec.

Right. But just for clarity, we're not removing the "default 
connection". Creating a PeerConnection will result in a connection 
(naturally the app in the other browser must also create a PC, and the 
signaling messages must be passed between them and so on for it to 
happen) being set up. My assumption has been that it is set up and kept 
alive using ICE, but I guess other methods are discussed.

> Whether or not it's mandated, that's not the right place to mandate it.
>> I do see a simplicity in using ICE for keep-alive and consent freshness
>> as this is likely applicable for all transport protocols that we need
>> (as they will be over UDP) and aren't TCP to a relay or server.
>>
>> I do also notice that there are desire for alternative solutions.
>>
>> Lets keeps the discussion going.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb