Re: [multipathtcp] explicit mode for smartphone scenario

[Olivier Bonaventure <[e-mail]>]

Phil,
>
> So continuing to concentrate first **specifically** on the solution for
> this use case:
>
> <<. The other scenario involves an MPTCP-enabled smartphone, with LTE
> and WiFi, plus a proxy in the operator’s network.>>
>
> And now looking at “explicit” solutions – meaning the smartphone is
> configured to know about the proxy.
>
>
>
> I’d like to understand better the pros and cons of the solution proposed
> in the plain-mode draft and the solution that uses SOCKS protocol
> between smartphone and the proxy.  (I’m not sure where /if the latter is
> fully defined, described in
> https://www.ietf.org/proceedings/93/slides/slides-93-mptcp-3.pdf  and
>  https://dial.uclouvain.be/downloader/downloader.php?pid=thesis%3A366&datastream=PDF_01

There are different variants of SOCKS that can be used. They mainly 
depend on the number of messages that are used to authenticate the 
smartphone. In
https://inl.info.ucl.ac.be/system/files/PAM2016_54-deconinck.pdf
we used a SOCKS proxy that was configured with very weak authentication 
to minimise the additional delay for the establishment of the TCP 
connections. I don't know which type of authentication has been deployed 
in Korea.

There are two issues that need to be considered when deploying proxies 
for the smartphone use case :

a- minimise the end-to-end connection establishment time. Ideally, it 
should be possible to create an end-to-end connection with a single 
handshake and thus a single end-to-end rtt. When we analysed real 
smartphone traffic, we found that many connections were very short. 
SOCKS requires additional rtts between the smartphone and the proxy to 
establish eash connection. The plain-mode minimises the end-to-end 
connection establishment delay compared to SOCKS proxies.

b- authenticate the client (resp. the proxy) on the proxy (resp. the 
client) and possibly encrypt the traffic. SOCKS supports several 
mechanisms to authenticate the client and some implementation of SOCKS, 
such as the popular shadowsocks that was used in the PAM paper mentioned 
above, support proprietary authentication scheme. Encrypting wireless 
traffic makes a lot of sense in the smartphone scenario since it will 
likely hop from one WiFi network to another. Note that some operators 
could want to restrict the utilisation of the proxies on cellular and 
WiFi networks that they operate. On such networks, the IP addresses 
assigned by the operator could be sufficient to authenticate the 
client/proxy.




Olivier