Re: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)

Hello,

On 07/11/16 - 15:03:49, mohamed.boucadair@orange.com wrote:
> I'm not sure it is that clear we need to systematically include MP_CAPABLE option in the SYN to the ultimate server. I see some value there...but also some side effects. I'm reiterating what I already said in this thread: 
> 
> (+) I see "a big benefit" for some operators to offload the MTPCP proxies if the server is MPTCP-capable.

I think it is not only for "offloading" but also just to allow for native
MPTCP. When there is a choice between native MPTCP and proxied MPTCP, the
former should always be preferred. I guess we all agree on that.

> (-) I don’t see "a big benefit" for the client from a QoE perspective, because they already have the MPTCP experience with the network assistance (network aggregation, path resiliency). 

When MPTCP goes end-to-end, the routing is optimal because the TCP-subflows
don't have to go through a detour to reach the proxy. The path through the
proxy is always less or equally as good as the direct path.

>From a QoE perspective I see a benefit in that the native server has more
info on the traffic-characteristics it is sending to the client. So it can
optimize based on this. This info (coming from the server-side) is not
available to the proxy.

> (-) I don’t see "a big benefit" for the client if the MPTCP-capable server decides to use a given path to place data, while that path is subject to a data volume quota. This means that the client will be mono-path quickly if an MPTCP-capable server adopts some traffic distribution schemes.

This shows that we need signalling on an MPTCP-connection so that the client
can tell the server "don't send on this subflow now". We actually already have
this with the MP_PRIO-option, but something more sophisticated might be needed.

While a proxy might have access to the data-quota and can schedule traffic
based on this, data-quota is not the only variable that makes one want to
avoid cellular. If the device is a mobile device, battery-constraints come
into play as well.

Christoph

>  
> That said, I have no problem to leave this as a configurable parameter. A configuration knob can be supported to instruct the MCP about the behavior to follow. Also, a white list of servers can be provided to the MCP. 
> 
> This is exactly the kind of technical considerations for which we need a formal WG document so that we can record the WG decision.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]
> > Envoyé : dimanche 6 novembre 2016 22:12
> > À : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; Alan Ford
> > Cc : multipathtcp@ietf.org
> > Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> > 
> > 
> > It's clear that the MCP should send the MP_CAPABLE option in the SYN
> > towards the destination server and fallback to TCP is this fails. Since
> > there are some middleboxes that continue to silently drop the MP_CAPABLE
> > option, the MCP should be able to maintain a list of destination servers
> > where it had to fallback to regular TCP (e.g. after n retransmissions of
> > the SYN with MP_CAPABLE as suggested in RFC6824) and no attempt to use
> > MPTCP for these destinations. This cache should be reset on a regular
> > basis to probe again the destination servers.
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp