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

["DRAGE, Keith (Keith)" <[e-mail]>]

> 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stefan Håkansson
> Sent: 06 October 2011 14:48
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must 
> work through interface switching
> 
> On 10/06/2011 03:04 PM, [e-mail] 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, [e-mail] 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 [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >> _______________________________________________ rtcweb 
> mailing list 
> >> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>