Re: [multipathtcp] towards a potential work item on two-ended proxy

[Olivier Bonaventure <[e-mail]>]

Phil,

> We started the discussion yesterday on a potential new work item on
> “two-ended proxy scenario” – where there’s an MPTCP proxy in both the
> CPE and an aggregation point (for instance). The current charter is that
> one end host is MPTCP.
>
>
>
> If I can try and summarise the brief discussion yesterday (plus some
> side discussions) (please correct my inaccuracies):
>
> -          there are now deployments & products with an MPTCP proxy at
> each end, plus planned Broadband Forum work (WT-348 is about to be made
> public, with subsequent work to follow). So IETF work is timely (eg help
> allow an operator to buy CPE from one vendor and aggregation gateway
> from another vendor).

I fully agree
>
> -          However, some people object to going beyond the current
> charter’s “one-ended proxy scenario” (since the “two-ended proxy”
> discourages deployment of MPTCP to all the end hosts, which is the
> ultimate goal)

I don't think that deploying MPTCP proxies would discourage the 
deployment of MPTCP end-to-end. This deployment shows that MPTCP is a 
valid solution to some problems where bandwidth can be aggregated and 
would convince users that MPTCP would be a good way to solve their problems.

The scenario is the following :

client ----  CPE --------- HAG -------- server
               +-------------+


The network operators want to use MPTCP between the CPE and the HAG 
because MPTCP is from a technical viewpoint the best solution to react 
to congestion and varying traffic conditions (delay, losses, ...) on the 
two access networks that are bonded. Since today's clients and servers 
only support regular TCP, operators want to have :
  - a TCP<->MPTCP proxy on the CPE
  - a MPTCP<->TCP proxy on the HAG

Note that since the CPE and the HAG support MPTCP by design, they could 
be MPTCP<->MPTCP proxies and support MPTCP end-to-end as a series of 
proxied connections. Proxied connections have two advantages in wireless 
networks compared to regular end-to-end MPTCP connections :
  - feedback loops are much shorter, which improves performance as shown 
by the deployment of various TCP optimisers in mobile networks
  - network operators can apply policies to prefer one network over the 
other

If the IETF works on this problem, we can ensure that the solution will 
support by design a scenario where MPTCP is used on the client and MPTCP 
is used as well on the server side.

>
> -          There are two proposals (transparent & plain mode:
> draft-boucadair-mptcp-plain-mode-08 &
> draft-peirens-mptcp-transparent-00). Are these addressing different use
> cases, or do we need to choose between them? would a (potential) charter
> item be to standardise existing draft(s), or to solve a problem /scenario?


The use case is the same : hybrid access networks. They both rely on 
MPTCP-MPTCP proxies. The deployment mode is different.

The plain-mode draft allows the HAG to be placed anywhere in the network 
and the destination address of the SYN is used to reach the HAG. The 
plain-mode option, included in the SYN, contains the final destination 
of the end-to-end connection.

The transparent-mode draft assumes that the HAG is placed on the path 
to/from the CPE. This implies that there is no need to change the 
destination address of the SYN to reach the HAG.

>
> -          I think there was mention (by Wim??) that there’s a third
> proposal – how does this fit in, or did I get it wrong?
>
> -          One aspect of the plain mode draft is to allow transport of
> UDP traffic as well as TCP traffic. I think this is a proposal that
> should be discussed separately  - for instance it needs INT-area expertise.

Agreed, we should focus on the TCP discussion in this WG

> I think it would be good to have more discussion before attempting to
> write some potential charter text (and then seeing if there’s consensus
> for it).
>

Olivier