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

[<[e-mail]>]

Hi Christoph, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : lundi 7 novembre 2016 17:06
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; Mirja Kühlewind; Alan Ford;
> [e-mail]
> Objet : Re: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP
> proxy charter item)
> 
> Hello,
> 
> On 07/11/16 - 15:03:49, [e-mail] 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.

[Med] I hear you Christoph, but I think we need to elaborate a little bit further to understand what are the incentives for an MCP to be removed from the path. Optimizing the use of MCP resources has a clear benefit for an operator because this is about OPEX/CAPEX.

> 
> > (-) 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. 

[Med] You are making an invalid assumption here about forwarding. This is deployment-specific. An MCP proxy can also be on-path. BTW, path stretch is a requirement for deciding the location of an MCP. This is clearly mentioned the deployment I-D.


The path through the
> proxy is always less or equally as good as the direct path.

[Med] You are right. My comment was not about the basic delay transfer, but about the "MPTCP experience": network aggregation, path resiliency.  Of course a proxy may fail, but means to protect carrier grade functions are widely in use in operators networks.

> 
> 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.

[Med] I see your point, but there are cases (mainly in the cellular world) that may require some knowledge of the radio cells to react quickly to congestions. FWIW, some experiments were conducted to define an API that can be exposed to a content provider to help for direct delivery without involving a proxy. The server has not to be aggressive to the network. Having information from the network to the server, and vice versa would be ideal.  

> 
> > (-) 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.

[Med] Agree. Having an option would help but it still this is tricky because an MPTCP client may not have access to "subscription" information. It may use the interface technology as a hint, but still this a hint. Other complications may arise to acquire such information.

> 
> 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.

[Med] Agree, too. 

> 
> 
> 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:[e-mail]]
> > > Envoyé : dimanche 6 novembre 2016 22:12
> > > À : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; Alan Ford
> > > Cc : [e-mail]
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multipathtcp