Re: [multipathtcp] [MPTCP] draft-deng-mptcp-mobile-network-proxy-00

[Olivier Bonaventure <[e-mail]>]

Hello,

>
>     [xcs]Question for clarification: How does the MPTCP proxy know the
>     binding information between the IP and RAT ?  The mobile node knows
>     which IP is allocated from which RAT, but it is very hard for the
>     MPTCP Proxy in the core network to know these mapping information.
>
>
> *[dll] For 3GPP access networks, the core knows the RAT type as the time
> of PDP connection setup. For WLAN, there has been interworking standards
> via PDG (packet data gateway) which does the IP binding. So the core
> network knows the mapping, and there is a need to integrate MPTCP proxy
> with existing architecture to get this information.*

For MPTCP, the client gets several IP addresses, say one from the WLAN 
and one from the 3G network. A proxy solution should allow the client to 
start the MPTCP connection through the proxy either via the WLAN 
interface or via the 3G interface. It should not be bound to a specific 
network (say 3G) and force the client to always start over this network. 
There are mobility scenarios where only one network is available when a 
connection starts and this connection must pass through the proxy to 
benefit from mptcp in the future.

>     ____
>
>     One possible solution is the PCRF (defined in the 3GPP) to provide
>     these binding information to the MPTCP proxy if the MPTCP proxy
>     performance the traffic mediation or let the mobile to do the
>     traffic mediation.
>
>
> *[dll] I agree that interface with PCRF could be a solution to provide
> binding information from the network side, as well as acquiring
> mediation policy.*

An MPTCP proxy should not be restricted to a given technology. The 
client should be able to learn the address of the proxy that it needs to 
use (e.g. based on its location, subscription information or the network 
that it is currently connected to, ...). There could be some way to 
distribute this information from the 3GPP network, but it should not be 
the only way

>     ____
>
>     ____
>
>     Another question is how the rules (e.g. "always prefer Wi-Fi over
>     3GPP") are provided to the MPTCP Proxy or the mobile ? For the MPTCP
>     proxy, it is again the PCRF; for the mobile , it is the ANDSF ?____
>
>
> *[dll] Yes, PCRF would be a candidate in the case of proxy mediation and
> ANDSF has been proposed to be used by 3GPP for network selection.
> However, just for discussion, I personally prefer proxy-based mediation,
> as it may not always be proper to rely on the terminal for
> network-driven policy enforcement. Therefore, I would suggest we
> **currently **focuse on proxy-mediation case. Would you agree?*
>

In the case of WLANs, and in particular WLANs that are not controlled by 
the network operator, the terminal has often more information about the 
quality of the network (both WLAN and 3G) than the network itself. We 
should exploit this information and not only rely on the network.



>     [xcs] it will benefit the user if the user’s expense of data usage
>     is reduced, if the WiFi connection is available and charging fee is
>     very low, maybe all the traffic from the 4G are moved to the WiFi by
>     the MPTCP proxy, and the mobility and QoS of the service maybe
>     aren’t ensured, so it is proposed to adding the following sentence
>     to the end of this chapter:____
>
>     *The QoS/QoE/Service continuity of the current data services are
>     still kept when the MPTCP proxy is used to reduce the user’s usage
>     expenses.*
>
>
> *[dll] Good point. I agree.*


Reducing the user expenses (assuming that WiFi is cheaper than 3G) is 
one use case for an MPTCP proxy, but this is by far not the only one. 
Other use cases include :

  - improving performance by using simultaneously WiFi and 3G
  - improving quality of experience by allowing the terminal to use 
either WiFi or 3G automatically without asking the user to manually 
switch between the two interfaces
  - avoid being stuck with "open" WiFi networks that provide an IP 
address but use a captive portal where the user has to log in. Today, 
many users of smartphones are frustrated when their smartphone stops 3G 
to attach to such a WiFi network that they cannot use (but the 
smartphone tries sometimes for several minutes)
  - ...

>     ____
>
>     ____
>
>     A assumption for reducing user expense is that the WiFi connection
>     is activated beforehand, but sometimes the WiFi connection isn’t
>     activated or a wrong WiFi AP is selected by the user( that MPTCP
>     Proxy can’t access the WiFi IP flow), that is, one hand, the network
>     need to control the MPTCP Proxy to mediate the IP flows, another
>     hand, the network should tell the mobile to open which RAT/WiFi to
>     make the MPTCP Proxy work.  i.e. the network should provide some
>     information to the UE , to guide the UE to select and open another
>     RAT to enable the MPTCP.____
>
> *[dll] I agree that it is of great value for mobile terminals to be more
> intelligent in enabling multiple interfaces based on network provided
> information. But how it is done seems to be out of scope of a MPTCP
> proxy discussion.*

A proxy should not be limited to some specific networks that are 
controlled by the network operator. Users expected to be able to use 
whatever WiFi for which they have the necessary credentials and MPTCP is 
able to use whatever WiFi has long as it provides a reachable IP address.



Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be