Subject: [rtcweb] Interface switching use case and the basic needs

From: <[email-masked]>
Date: Tue, 12 Jun 2012 20:54:06 +0000

Hi,

Here is some input on the interface switching use case from mobile device perspective:

Most today's mobile devices (smartphones, tablets) work so, that only a single interface is connected at a time. This is for power conservation reasons, plus no-one has figured out what to do with the second active interface. In practice the two interfaces are always cellular (of some sort) and Wi-Fi. A typical policy is that any Wi-Fi is preferred over cellular, but in theory some Wi-Fi networks could have a lower priority too. If a higher priority interface (network) becomes available, the device connects to it, and after that, switches off the lower priority one. When the preferred network becomes unavailable, the device tries to connect to the second best option. 

Applications usually have no control on this. For instance, if the user is having a VoIP call over cellular and walks to Wi-Fi coverage, interface swithing is done (after the Wi-Fi is discovered, which may take a few minutes depending on the scanning interval), and the call is lost (unless the app uses some magic to keep it up). Depending on the environments, apps usually listen to events indicating interfaces going up and down. Many apps today are capable of dealing with this. For instance apps that have persistent TCP connections simply re-establish them over the new interface. Depending on the app protocol they will also have to do things like re-register (SIP) on top of that. If there's nothing time critical going on, the user won't notice anything. In the worst case the other end is just sending something over TCP when the connection is abandoned and that requires some app layer recovery. 

I don't know how well browsers and web apps in general deal with this. HTTP is easy to deal with, as its state is not tied to e.g. a particular TCP connection. Pending requests, for instance hanging GETs, can be re-issued over a new TCP connection. How about Websocket protocol? Is it possible to simply re-establisth its TCP connection without the JS app using it noticing? I suppose so, but also the recovery of lost data has to be dealt with. The main question is whether the JS app would need to know/react in any way. In WebRTC the real-time sessions would often be "signaled" over Websockets or hanging HTTP GETs, so making that part recover smoothly from underlying TCP connections getting dropped would be essential.

The real-time media recovery/update would be a great feature, but let's keep in mind also the more basic needs. Can they be dealt with a smart browser implementation, or is there a need to expose something to the JS app too?

Markus

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jun 2012 15:52:03 -0700

On 12 June 2012 13:54,  <[email-masked]> wrote:
> Most today's mobile devices (smartphones, tablets) work so, that only a single interface is connected at a time. This is for

BTW, this one interface at a time behaviour is really annoying in some
situations.  WiFi networks frequently require sign-on, which means
that you migrate to the WiFi and you spend ages mucking around with
the login, or you have to turn off WiFi in order to reassociate with
the MME.  Either way, you have a significant down time window.

This happened to me at SFO on the way over, when I realized that my
"mobile boarding pass" was necessary to enter the security line.  It
took a couple of minutes to resolve.  This is a bad user experience as
a result of this sort of rule, applied blindly.

 > How about Websocket protocol?

That doesn't work.  The application is forced to recover.  Most of the
reasons for using websockets involve tying some sort of state to the
connection.  Sure, that's not robust, but it is easier to fail at that
point than spend the effort dealing with either statelessness (for
which you are using HTTP anyway) or state recovery, which is expensive
to implement.

> The real-time media recovery/update would be a great feature, but let's keep in mind also the more basic needs. Can they be dealt with a smart browser implementation, or is there a need to expose s…

Sure, the JS app gets a disconnect from websockets.  It had better
deal.  The fact that you have had a switchover does require
effectively a complete reboot of ICE, which a realtime app ultimately
needs to deal with by signaling candidates...at a minimum.

This is covered by what EKR sent out and I'm sure that he will have a
proposal for the API around this.  If he doesn't do that soon, I'll
propose something he wont like.

--Martin

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 10:08:46 +0000

[email-masked] wrote:
>> Most today's mobile devices (smartphones, tablets) work so, that only
>> a single interface is connected at a time. This is for
>
>situations.  WiFi networks frequently require sign-on, which means that you
>migrate to the WiFi and you spend ages mucking around with the login, or you
>have to turn off WiFi in order to reassociate with the MME.  Either way, you
>have a significant down time window.
>

Yes, this is a well-known problem. Some naïve implementations are happy after they get an IP address from Wi-Fi to switch to it and shut down cellular. At that point you may still be blocked by a captive portal asking for sign-up or accepting terms and conditions. Fortunately things are improving with more Wi-Fi networks using automatic authentication like 802.1x, WISPr, etc. But this problem will not go away in the near future. 

>That doesn't work.  The application is forced to recover.  

OK, that's what I was afraind of. The problem is pushed to every single Javascript developer using Websockets. 

>
>Sure, the JS app gets a disconnect from websockets.  It had better deal.  The
>fact that you have had a switchover does require effectively a complete
>reboot of ICE, which a realtime app ultimately needs to deal with by signaling
>candidates...at a minimum.
>

The minimum indeed is that we have the JS APIs in place that allows the app to learn about the switchover and recover from it. 

>
>This is covered by what EKR sent out and I'm sure that he will have a proposal
>for the API around this.  If he doesn't do that soon, I'll propose something he
>wont like.
>

Good.

Markus

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 10:08:46 +0000

[email-masked] wrote:
>
>So my question is, does this Interface switching use case support dual radio or
>not?
>
>If it support, we can have a solution based on the assumption that the
>browser will receive two access info, and both can be used, or If it does not
>support, I don't think the access transfer delay can be tolerated by the user.
>Even we have some solution in the JS and browser layer, the user may switch
>off the call before the call has recovered.
>

Currently the interface switching in most OS's happens in hard-handover way, i.e. the two interfaces are not in use at the same time. Even if the two radios were up at the same time for a while, I believe on the IP level the default route points only to a single interface at a time. So the browsers and web apps should assume break-before-make handovers do happen and try to deal with them.

Having said that, it is indeed a good idea to keep the old interface up at least for a while after the new one is activated. That gives protocols (like MPTCP) and apps at least the chance to do a make-before-break transition. There is no problem keeping up Wi-Fi and cellular interfaces at the same time from the radio perspective. So, this is another scenario that browsers and web apps (and the JS APIs) should support, in case they run on a nice platform able to offer it them, and the network coverage also makes it possible. I don't know how complex events that APIs can convey, but this would be something like: "A new higher priority interface is available. The lower-priority interface is still up for a while, but you'd better move your traffic/state to the new one, as the old one may be gone at any point." 

Markus

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 13 Jun 2012 13:45:50 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 13 juni 2012 12:09
> To: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Interface switching use case and the basic needs
> 
> 
> >So my question is, does this Interface switching use case 
> support dual 
> >radio or not?
> >
> >browser will receive two access info, and both can be used, or If it 
> >does not support, I don't think the access transfer delay 
> can be tolerated by the user.
> >Even we have some solution in the JS and browser layer, the user may 
> >switch off the call before the call has recovered.
> >
> 
> Currently the interface switching in most OS's happens in 
> hard-handover way, i.e. the two interfaces are not in use at 
> the same time. Even if the two radios were up at the same 
> time for a while, I believe on the IP level the default route 
> points only to a single interface at a time. So the browsers 
> and web apps should assume break-before-make handovers do 
> happen and try to deal with them.
> 
> Having said that, it is indeed a good idea to keep the old 
> interface up at least for a while after the new one is 
> activated. That gives protocols (like MPTCP) and apps at 
> least the chance to do a make-before-break transition. There 
> is no problem keeping up Wi-Fi and cellular interfaces at the 
> same time from the radio perspective. So, this is another 
> scenario that browsers and web apps (and the JS APIs) should 
> support, in case they run on a nice platform able to offer it 
> them, and the network coverage also makes it possible. I 
> don't know how complex events that APIs can convey, but this 
> would be something like: "A new higher priority interface is 
> available. The lower-priority interface is still up for a 
> while, but you'd better move your traffic/state to the new 
> one, as the old one may be gone at any point." 

Who is setting the "priority" of the interface? Should not the web app have a say whether the traffic
should be kept on a particular interface or not?

> 
> Markus
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 12:35:28 +0000

Hi,

[email-masked] wrote:
>>"A new higher priority interface is available. The
>> lower-priority interface is still up for a while, but you'd better
>> move your traffic/state to the new one, as the old one may be gone at
>> any point."
>
>Who is setting the "priority" of the interface? Should not the web app have a
>say whether the traffic should be kept on a particular interface or not?
>

This is usually a system-wide policy enforced by the connection manager. Individual apps can't influence it. We do have a capability in Symbian by which the apps can set preferences, but it has not been used very much - app developers have no clue about interfaces. So far it has been quite a strict requirement that we want to keep only one radio interface active at a time to save power. The apps will just have to live with that.

There can be some special apps like IMS and MMS that have their own policies, mainly because they don't work over Wi-Fi (no security, no NAT traversal, accounting is based on IP address etc. reasons). But normal apps have very limited powers. Web apps probably the worst since they are additionally restricted by the web runtime's capabilities.  

Markus

---

From: Lishitao <[email-masked]>
Date: Thu, 14 Jun 2012 01:12:47 +0000

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 G?ran Eriksson AP
发送时间: 2012年6月13日 19:46
收件人: [email-masked]; [email-masked]
主题: Re: [rtcweb] Interface switching use case and the basic needs

  I think the OS should set the "priority", only the OS know which interface has the better signal. The app can get such information from the browser, and trigger the transfer.