Re: [multipathtcp] Fwd: Fw:New Version Notification fordraft-deng-mptcp-mobile-network-proxy-00.txt

[Olivier Bonaventure <[e-mail]>]

Hello,

> http://www.ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy-00.txt
> <http://www.ietf.org/internet-drafts/draft-deng-mptcp-mobile-network-proxy-00.txt>
>

Please find below some first comments on your draft.

 >3 Considerations for MPTCP Proxy

An important motivation that is missing from the draft is that nowadays, 
although there are hundred of millions of MPTCP enabled smartphones, 
there are very few servers that support MPTCP. In the past, measurements 
have shown that TCP extensions (RFC1323, SACK, ...) have been deployed 
first on clients and that it took many years to enable these TCP 
extensions on the server side.

The main reasons for the slow evolution on the server side appears to be :

  - the need to upgrade the load balancers, firewalls and other 
middelboxes in front of the servers
  - the desire of system administrators to only use very stable 
operating system releases

On the server side, we may have to wait several years until Multipath 
TCP becomes widely deployed. In the mean time, a proxy-based solution 
that supports all TCP connections would enable clients such as 
smartphones to benefit from Multipath TCP.


 > 4.1 Dynamic traffic offloading based on network information


> For bulk data transfer who is satisfied with best-
>    effort delivery, Wi-Fi would be a great choice. But the vertical
>    partition does not fit everywhere for the wireless condition itself
>    is quite dynamic and hard to predict. It is important to implement
>    adaptive offloading mechanisms in order to achieve higher resource
>    utility with ever changing radio environment for a possibly moving
>    terminal based on network status, e.g. cell load, AP's signal
>    intensity, user's subscription type, etc.

Our experience with Multipath TCP on smartphones shows that the main 
benefit of MPTCP compared to other solutions where the network would 
favor WiFi over 3G or the opposite is that MPTCP has all the information 
about the current quality of the WiFi and 3G links.

We've seen WiFI access points that provide a very good SNR, but are 
attached to a crappy and overload ADSL link.

We've also seen areas where 3G does not work efficiently while WiFi 
works and the opposite. Sometimes, by moving a few meters, the 
smartphone gets connectivity or no connectivity from one wireless 
network. It seems unlikely that a static solution that would say always 
prefer 3G for chat and always prefer WiFi for video would always work. 
There are many situations where you need both WiFi and 3G at the same 
time, e.g. to perform a seamless handover during a few seconds while moving.

> 4.2 Resource pooling for reduced expense


There are many WiFi networks to which the user has credentials and that 
he/she wants to use that are not controlled by 3G operators. See for 
example campus networks covering schools, some city-wide networks being 
deployed, community networks like FON that aggregate millions of access 
points in Europe. Users expect to be able to use all these networks more 
efficiently thanks to Multipath TCP.

> 5.1  Protocol transition
>
>    To allow a MPCTP-enabled UE to make full use of the multiple radio
>    interfaces even if it is communicating with a non-MPTCP server, the
>    proxy should support
>
>    (a) Detection of UE's MPTCP capability;
>
>    (b) Negotiation with MPTCP UE on behalf of non-MPTCP SP;
>
>    (c) Translation/Mapping between TCP and MPTCP sessions.


For points a and b, do you have any requirements beyond the utilization 
of the standard MP_CAPABLE option that allows to perfor this negotiation ?

(c) requires the ability to support MPTCP upstream of the proxy and TCP 
downstream of the proxy. In contrast with application level proxies such 
as HTTP proxies, an MPTCP proxy should be application agnostic and 
should support any type of application that runs on top of TCP.


> 5.2  Traffic mediation
>
>    (a) Anchoring of sub-flow traffic: On one hand, it is not always
>    possible for a single GW be sitting on the path of every sub-flow
>    from a MPTCP session, hence explicit traffic anchoring to enable a
>    single point of general control over MPTCP sub-flows should be
>    considered.


This can be achieved by providing to the smartphone the addresses of the 
proxies so that the smartphone uses them as relays when creating new 
MPTCP connections. Implicit proxies with in-network redirection like 
WCCP are possible as well, but as you note, it is difficult to ensure 
that all traffic will always flow through a given part of the network, 
especially if the transport connections are long lived

>    (b) Mediation of sub-flow traffic: On the other hand, for fine-
>    grained mediation of sub-flow traffic, both static and dynamic
>    selection/offloading/pooling policies should be allowed.

I'm not sure I completely understand what you mean by subflow traffic

>    For
>    instance, "always prefer Wi-Fi over 3GPP" could be a static policy
>    for bulk data transfer services, while "use 3GPP only for backup
>    unless Wi-Fi is congested" could be a dynamic offloading policy for a
>    un-prioritized VoIP service.

Do you foresee more complex policies than the ones allowed by using the 
backup bit defined in Multipath TCP ? Would these policies be imposed by 
the network operator, configured on the client devices ?


Best regards,



Olivier


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