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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Fri, 07 October 2011 10:43 UTC

Return-Path: <keith.drage@alcatel-lucent.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 B581A21F8A35 for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 03:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.853
X-Spam-Level:
X-Spam-Status: No, score=-105.853 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 y5ADrYkgwVyr for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 03:43:19 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9B21F88B6 for <rtcweb@ietf.org>; Fri, 7 Oct 2011 03:43:16 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p97AiU13006424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Oct 2011 12:46:26 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 7 Oct 2011 12:46:19 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: =?iso-8859-1?Q?Stefan_H=E5kansson?= <stefan.lk.hakansson@ericsson.com>, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
Date: Fri, 7 Oct 2011 12:46:17 +0200
Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
Thread-Index: AcyELrJcJEPtOXbTSYyDYS5GDAfcqgArzqLw
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE220D4C410@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <4E89AD52.5000402@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620D5D62@008-AM1MPN1-043.mgdnok.nokia.com> <4E8DB1A5.1000800@ericsson.com>
In-Reply-To: <4E8DB1A5.1000800@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
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: Fri, 07 Oct 2011 10:43:21 -0000

> 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).
> When people end up phrasing something as "It MUST be possible... " what they normally mean is:

"The mechanism MUST support ..."

Rather than

"Implementations MUST support ..."

Or, else some form of use requirement.

But choose which you want.

Regards

Keith 

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Håkansson
> Sent: 06 October 2011 14:48
> To: Markus.Isomaki@nokia.com
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must 
> work through interface switching
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>