Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 23 September 2011 07:18 UTC
Return-Path: <magnus.westerlund@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 A66B421F8ABD for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 00:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.528
X-Spam-Level:
X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ErAt9rhbf8NQ for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 00:18:55 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9056A21F8ABB for <rtcweb@ietf.org>; Fri, 23 Sep 2011 00:18:54 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ce-4e7c337700f0
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.99.20773.7733C7E4; Fri, 23 Sep 2011 09:21:27 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 09:21:27 +0200
Message-ID: <4E7C3375.2070404@ericsson.com>
Date: Fri, 23 Sep 2011 09:21:25 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Randell Jesup <randell-ietf@jesup.org>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@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>
In-Reply-To: <4E7B6774.7040601@jesup.org>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 07:18:55 -0000
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. 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. 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] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Jonathan Lennox
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] STUN for keep-alive sisalem
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Göran Eriksson AP
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- [rtcweb] consent freshness [was RE: STUN for keep… Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Eric Rescorla
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive Cullen Jennings
- Re: [rtcweb] STUN for keep-alive Michael Tüxen
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Harald Alvestrand
- Re: [rtcweb] consent freshness [was RE: STUN for … Stefan Håkansson LK
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo