Subject: Re: [multipathtcp] MPTCP carrying UDP
From: <[email-masked]>
To: "[email-masked]" <[email-masked]>,Sébastien Noel <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 24 Nov 2016 10:32:09 +0000
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>

Hi Olivier,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:[email-masked]]
> Envoyé : mercredi 23 novembre 2016 15:08
> À : BOUCADAIR Mohamed IMT/OLN; Sébastien Noel; [email-masked]
> Cc : [email-masked]
> Objet : Re: [multipathtcp] MPTCP carrying UDP
> 
> Med,
> >
> >> -----Message d'origine-----
> >> De : multipathtcp [mailto:[email-masked]] De la part de
> >> Sébastien Noel
> >> Envoyé : mercredi 23 novembre 2016 12:09
> >> À : [email-masked]
> >> Cc : [email-masked]
> >> Objet : Re: [multipathtcp] MPTCP carrying UDP
> >>
> >> Phil,
> >>
> >>> Do people have any experimental results /experiences they could share
> of
> >>> running UDP applications over MPTCP sub-flows?  Would be interested to
> >> hear
> >>> about the issues.
> >>> I guess VoIP and Quic would be the most interesting ones.
> >>
> >> To understand the interactions between QUIC and an underlying MPTCP
> >> transport, we performed some experiments by running QUIC over OpenVPN
> >> that runs itself over an MPTCP connection. This is the closest scenario
> >> to what you are discussing based on existing open-source software.
> >
> > [Med] The schema we are investigating does not include this cascaded
> layers. It is only UDP payload transported in plain MPTCP connections.
> 
> 
> The cascading layers increase the CPU and byte overhead, but the
> interactions between the congestion control schemes and the reliablity
> mechanisms remains.

[Med] My point is that we need to isolate the impact of those cascaded layers on the CPU/Performance efficiency from pure interactions between the CCs.  

 In the experiment, the CPU is not a concern given
> that PCs were used as routers. The byte overhead influences the maximum
> efficiency of the solution but not how it degrades when there is latency
> or losses. The degration comes form the coupling between the congestion
> control and the reliability mechanisms of both QUIC and MPTCP.
> 
> >> OpenVPN includes some framing to carry UDP and
> >> encryption/authentication. These mechanisms add CPU overhead and byte
> >> overhead compared to transporting QUIC over a plain MPTCP connection,
> >> but this does not change the results of the experiments.
> >>
> >
> > [Med] I wouldn't drop that conclusion as the overall performance depends
> also on the overhead prepended to packets to be injected over the tunnel.
> >
> > Putting that aside, can you please indicate how the traffic is
> distributed among available subflows? FWIW, the target traffic
> distribution policy for the hybrid access is to use the fixed line first,
> and then grab some resources from the cellular link if needed. So the
> target objective is not 1+1!
> >
> 
> That's a policy issue. The experiment was whether both links can be used
> efficiently when running QUIC over MPTCP to transport a long file. If
> your policy delays the utilisation of the second link when the first is
> full, then you will get even lower performance since MPTCP will delay
> the utilisation of the subflows.

[Med] It is a policy, that's true... but it is a key point to decide what are acceptable performance or not. Assuming 1+1 is putting the bar too high for the deployments plans I'm aware of. 

[SNIP]

> >>
> >> As you can see, with QUIC over MPTCP sub-flows, performance seems to
> >> drop as soon as you have an unreliable medium or as soon as you have
> >> latency
> >>
> >> The sames tests were performed again, but this time with HTTP over
> >> end-to-end MPTCTP, to have a point of comparison
> >
> > [Med] When do you say "end-to-end MPTCP" do you mean MPTCP is enabled by
> the client and the server?
> >
> 
> Yes.

[Med] I wouldn't use that as a reference. In order to have comparable results the reference IMHO is to have the same cascade layers for TCP flows that will be proxied into MPTCP connections. 

 Given our experience with TCP/MPTCP proxies, the result would have
> been the same with TCP/MPTCP proxies running on the two routers, but
> these proxies could not be integrated in this setup for practical reasons.

[Med] It would be more interesting if similar setup conditions are used to have fair comparisons.