Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

<Markus.Isomaki@nokia.com> Thu, 06 October 2011 13:18 UTC

Return-Path: <Markus.Isomaki@nokia.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 A570721F8B43 for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.781
X-Spam-Level:
X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599]
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 k7ZN8Y9+ExID for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:18:10 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD921F8B30 for <rtcweb@ietf.org>; Thu, 6 Oct 2011 06:18:10 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p96DKrYn028944; Thu, 6 Oct 2011 16:21:16 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 16:20:04 +0300
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 6 Oct 2011 15:20:03 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Thu, 6 Oct 2011 15:20:03 +0200
From: <Markus.Isomaki@nokia.com>
To: <magnus.westerlund@ericsson.com>, <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bwAAKV6AAAUGtUD//+VQgIAC914A//48VBA=
Date: Thu, 6 Oct 2011 13:20:01 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620D5D88@008-AM1MPN1-043.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <4E89C099.3000709@alvestrand.no> <E44893DD4E290745BB608EB23FDDB7620D3945@008-AM1MPN1-043.mgdnok.nokia.com> <4E89CBF1.8050207@alvestrand.no> <4E8C48F2.6090502@ericsson.com>
In-Reply-To: <4E8C48F2.6090502@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [88.114.26.217]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Oct 2011 13:20:04.0342 (UTC) FILETIME=[A8DC8960:01CC842A]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
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: Thu, 06 Oct 2011 13:18:11 -0000

Hi Magnus,

Magnus Westerlund wrote:
>
>Hi,
>(as individual)
>
>I would like to comment on two things around this with ICE restarts and what I
>believe Google Voice Talk does and its relation to the ICE spec.
>
>First of all I understand this being based on that the candidates are kept alive
>after the initial nomination so they are always ready. This is clearly allowed,
>but will definitely fail if the other part doesn't keep its ICE candidates alive,
>and do note that these might include TURN relay candidates also. Thus this
>practice is not without some resource consumption, even if it is only a STUN
>request every 15 seconds.
>

I agree that keeping candidates alive for an interface that is otherwise on stand-by is costly. For instance, if the media flows over Wi-Fi, but the device would like to keep the cellular interface candidates alive in case the user steps out of Wi-Fi coverage, it will be about double the radio power consumption. But there are some situations where doing this smartly might make sense. 


>Secondly, I understand that the alternative candidates are used without
>signaling to the other peer that the ICE connectivity checks and later
>nomination happens. This will not work for candidate pairs where the peer
>not having interface change happen to it is behind a middlebox with a address
>dependent filtering rule, i.e. practically all, unless the candidate pair hasn't be
>initially verified to work and kept alive without nomination due to lower
>priority for the whole call. 

Right. 

>Otherwise, this only works when both sides tries to
>use their candidates due to ICE restart signaling message or that the other
>peer also suspects path breakage and initiates an ICE restart implicitly based
>on lack of feedback and media traffic from peer.
>
>When it comes to handling interface changes in general. I do believe that we
>will need to support a signaled ICE restart. If not, the webapp can anyway
>emulate this at a higher resource consumption and likely longer media
>disruption by opening new peer connections.
>

Agree. It seems there is some flexibility how to do this, as long as the JS app just gets an event about the connectivity changes. So this seems to be the minimum thing needed.

>Cheers
>
>Magnus
>

Markus


>On 2011-10-03 16:51, Harald Alvestrand wrote:
>> On 10/03/2011 04:40 PM, Markus.Isomaki@nokia.com wrote:
>>> Hi Harald,
>>>
>>> Well, things may already be better than what I expected :)
>>>
>>>> The control channel needs to be reconnected too, of course, but
>>>> we're not so much in a hurry over that one.
>>> So you're not signaling anything at the point of the switch, but you
>>> have set two alternatives beforehand? In the mobile use case, the
>>> available interfaces come and go, so we can't offer all alternate
>>> candidates upfront. However, if we can keep the "old"
>>> interface up for a while after the "new" one appears, we can add the
>>> new candidate at that point.
>> Section 9 of RFC 5245 is the procedure for adding more candidates
>> during the call. It supports make-before-break:
>>
>> 9.1.1.1.  ICE Restarts
>>
>> An agent MAY restart ICE processing for an existing media stream.
>> An ICE restart, as the name implies, will cause all previous states of
>> ICE processing to be flushed and checks to start anew.  The only
>> difference between an ICE restart and a brand new media session is
>> that, during the restart, media can continue to be sent to the
>> previously validated pair.
>>
>>> This would be the so called make-before-break switch. The worst case
>>> is that we loose the old interface at the same time as new one comes
>>> available, so the new alternative can only be sent over the new
>>> interface AFTER the signaling has been reconnected. This would be
>>> break-before-make. If the underlying OS can handle multi-homing, we
>>> should in most cases only need the make-before-break type of
>>> switching. However, as we know, a device can run out of Wi-Fi
>>> coverate quite abruptly and it is not always clear that the cellular
>>> connectivity is fully up at that point.
>>>
>>> I don't know all nuances of ICE by heart, but is it so that the
>>> alternate candidates can be added in an offer at any point? In that
>>> case we should be able to cover most cases quite well.
>>>
>>> Markus
>>>
>>>> -----Original Message----- From: rtcweb-bounces@ietf.org
>>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald Alvestrand
>>>> Sent: 03 October, 2011 17:03 To: rtcweb@ietf.org
>>>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work
>>>> through interface switching
>>>>
>>>> The media channels in Google's ICE-based offerings (Google Talk
>>>> Video, Google Voice and Hangouts) all are able to survive an
>>>> interface change by utilizing the alternate candidate mechanisms in
>>>> ICE.
>>>>
>>>> Try this experiment: - Make sure your laptop has a working wireless
>>>> connection - Connect your laptop to wired Ethernet - Set up a Google
>>>> Talk Video call with someone - Yank out the Ethernet cord
>>>>
>>>> If all goes well, you should see exactly how much of a break this
>>>> causes to the call in practice. (If the call disconnects, please
>>>> file a bug - I'm sure there are cases we don't handle well.)
>>>>
>>>> The control channel needs to be reconnected too, of course, but
>>>> we're not so much in a hurry over that one.
>
>
>--
>
>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