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

Harald Alvestrand <harald@alvestrand.no> Fri, 23 September 2011 09:30 UTC

Return-Path: <harald@alvestrand.no>
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 CD85E21F8573 for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 02:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.805
X-Spam-Level:
X-Spam-Status: No, score=-108.805 tagged_above=-999 required=5 tests=[AWL=1.794, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QI1Eec2KMQOW for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 02:30:57 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9D21F84AC for <rtcweb@ietf.org>; Fri, 23 Sep 2011 02:30:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C09F39E0C4; Fri, 23 Sep 2011 11:33:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgwCiXfSrUw0; Fri, 23 Sep 2011 11:33:29 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 71CDB39E0BC; Fri, 23 Sep 2011 11:33:29 +0200 (CEST)
Message-ID: <4E7C5269.8050100@alvestrand.no>
Date: Fri, 23 Sep 2011 11:33:29 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
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> <4E7C3375.2070404@ericsson .com>
In-Reply-To: <4E7C3375.2070404@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Randell Jesup <randell-ietf@jesup.org>, "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 09:30:57 -0000

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