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

Stefan Håkansson <stefan.lk.hakansson@ericsson.com> Thu, 06 October 2011 13:45 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 0BD8221F8B4A for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level:
X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 0GXqzxHxRBdl for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:45:28 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCC21F8B3E for <rtcweb@ietf.org>; Thu, 6 Oct 2011 06:45:27 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e8db1b5824a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.77.20773.5B1BD8E4; Thu, 6 Oct 2011 15:48:37 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 15:48:22 +0200
Message-ID: <4E8DB1A5.1000800@ericsson.com>
Date: Thu, 6 Oct 2011 15:48:21 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <4E89AD52.5000402@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620D5D62@008-AM1MPN1-043.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620D5D62@008-AM1MPN1-043.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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:45:29 -0000

On 10/06/2011 03:04 PM, Markus.Isomaki@nokia.com wrote:
> Hi Stefan,
>
> Stefan Håkansson wrote:
>>
>> in terms of use case and reqs, do you see anything missing if you
>> look at
>> <http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-
>> requirements/>, section 4.2.3?
>>
>> In terms of technology I thought ICE would be able to handle this.
>>
>
> I agree ICE has the mechanisms to handle it to some extent, as new
> candidates can be added on-the-fly, e.g. when a device gets a new IP
> address via a newly connected interface. I guess the minimum
> requirement is that the entity generationg the ICE signaling messages
> needs to be able to learn about the existence of the new candidates
> immediately, so it can generate the new ICE "offer". I'm not sure
> where this is supposed to happen, but if it is the JS app that sends
> the "offers", there is a requirement that there needs to be an event
> in the API indicating that the set of local candidates has changed.

I agree. For the time being, the requirement is on a higher level - and 
quite badly phrased (I'm to blame):
"It MUST be possible to move from one network interface to another one"
I think it can be better put, and later when the model is decided it can 
be broken down (e.g to an event in the API).

Stefan

>
> Markus
>
>
>> On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com wrote:
>>> Hi all,
>>>
>>> There is one important requirement, which may not be critical
>>> today, but will
>> most likely be in the future.
>>>
>>> We can assume RTC-Web to be supported in devices like tablets,
>>> pads or
>> smartphones, that people carry around. We can also assume that when
>> such devices are carried around, their point of attachement to the
>> Internet will change, even so that the type of access network will
>> change, typically between something like HSPA/LTE and Wi-Fi. Today
>> this will always mean a change of IP address as well. In the future
>> we may have technologies such as (Proxy)Mobile IP in use that will
>> provide IP address preservation, but we can't really count on
>> that.
>>>
>>> How does this relate to RTC-Web? Interface switching usually
>>> happens at the discretion of the OS or some kind of connection
>>> manager. The browser or the web application environment has no
>>> control over it. At best it, or the JS application running
>>> within, can get some kind of signal of such event happening. For
>>> TCP-based client-server things (HTTP, Websocket) it is possible
>>> to react to this by re-establishing the lost TCP connections and
>>> state on top of them. This is indeed what many (native) apps are
>>> able to do today. There can be some smarter ways in the pipeline
>>> as well, such as multipath TCP, which would make the process of
>>> "transitioning" a TCP connection from one interface/IP to another
>>> potentially transparent to the application. But with peer-to-peer
>>> and interactive real-time, things get more complicated. It may of
>>> course be that the switching happens due to a sudden loss of
>>> coverage and is so slow, that voice or video calls are broken
>>> anyway. However, in many cases th
>> e
>>> old interface can be up while the new one is being established,
>>> and in
>> principle the total loss of connectivity can be avoided. In such
>> scenarios it would be realistically possible to update the ongoing
>> real-time sessions to a new IP address and port, if there were some
>> kind of end-to-end or server- assisted mechanism for it. Even a cut
>> of 1-2 seconds would not be as bad as a total loss of the session.
>>>
>>> What does this mean in terms of requirements? - The first-order
>>> requirement is that the browser and/or the JS app,
>> whoever needs to act, has to be able to get events of interface
>> switching in the same way as native apps can. If it were only the
>> browser who was required to get them, we could set standards aside,
>> and declare that the browser does this as any other app. But if it
>> is the JS app that needs to do something, then we may need
>> something new as a JS API. I have no clue at the moment if the JS
>> apps can learn about this kind of events. And this is clearly not a
>> RTC-Web specific requirement, but a generic one. I do know that
>> browsers or HTTP libraries can re-send requests etc. based on IP
>> address change, but I don't know what a JS Websocket client can do,
>> if anything.
>>> - The second requirement is that the media related APIs and
>>> transport
>> protocols (RTP) have to be flexible enough, that they can at least
>> be extended to work so that they do not assume that the session is
>> forever bound to a certain IP address/port in either end. How this
>> affects the system depends on what is actually standardized, for
>> instance if the SDP offer/answer model is included or not. But on
>> the generic level it could be something like this:
>>> - If the browser/JS app receives signaling/offer from its peer
>>> that
>> peer's RTP/UDP IP address/port has changed, it has to be able to
>> set these through the media API and re-run STUN checks or whatever
>> is required at that point. This has to be work so that the media
>> session can be otherwise continued, after the process is
>> completed.
>>> - If the browser/JS app receives an event that its own IP
>>> address/port
>> has changed (or is about to change), it has to be able to
>> re-initialize the RTP/UDP accordingly, re-establish its "signaling
>> connection and state" with its webserver, notify the peer about the
>> change, and re-run STUN checks etc. as needed.
>>>
>>> This sounds quite complicated so it may be that we don't want to
>>> add this as
>> a Day 1 requirement for RTC-Web. But I believe we should try to
>> design the APIs and protocols in such a way that this kind of thing
>> can be added later on. There could be other ways too, like MPRTP
>> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we
>> could look at.
>>>
>>> I suppose the less we standardize about the signaling and
>>> offer/answer, the
>> easier it might be to support these kinds of things as add-on. But
>> whatever we standardize, please keep the interface and IP address
>> change in mind. The outcome could be that we declare that transport
>> (MPTCP, MPRTP) has to deal with it, but eventually I think this
>> will have to work one way or the other.
>>>
>>> Regards, Markus _______________________________________________
>>> 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