Subject: [multipathtcp] Towards a Multipath TCP Proxy work item

From: <[email-masked]>
Date: Thu, 10 Nov 2016 19:17:25 +0000

Hi,
Perhaps this is speaking too soon, but it looks like the very active discussion is reaching some common understanding?

We're trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we'd assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we'd like discussion on these points to avoid getting into the fine details of one particular existing proposal.

What we'd appreciate is a summary of what the assumptions /understandings are about:

*         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the 'legacy' host it wants to communicate with)

*         If any impact is already envisaged on the current MPTCP protocol's fallback behaviour and coping with middleboxes

*         If we can agree that the solution is based on a new MPTCP option

*         If any impact is already envisaged on the current MPTCP protocol's semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4

*         If any impact is already envisaged on TCP's semantics, or any mods are needed, or assumptions about its behaviour, etc

*         If any impact is already envisaged on other existing transport protocol's semantics (presuming people still would like non-TCP in scope?)

*         Anything else that you think is needed in order to frame the work item

It may be clearer to do this for the two use cases (single-ended proxy, ie where only one host is MPTCP-enabled; and double-ended proxy, ie where neither host is MPTCP-enabled).

This may seem like a long list, but most of the answers can be "none" - we'll end up with just a short paragraph or a few bullets in the charter.

We'd also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.

Thanks
Phil & Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 11 Nov 2016 19:01:28 +0100

Phil,
>
> Perhaps this is speaking too soon, but it looks like the very active
> discussion is reaching some common understanding?

Let try a first answer to your questions for the single-ended Multipath 
TCP proxy work item.
I'll send my answers to the double-ended proxy in a separate email.
>
> What we’d appreciate is a summary of what the assumptions
> /understandings are about:
>
> ·         The scenario (for instance: the MPTCP-enabled host knows the
> address of the proxy (eg through configuration); and it knows the
> address of the ‘legacy’ host it wants to communicate with)

The typical use case is a smartphone that wants to combine its WiFi and 
cellular access networks to reach a server that does not (yet) support 
Multipath TCP.

> ·         If any impact is already envisaged on the current MPTCP
> protocol’s fallback behaviour and coping with middleboxes

I don't think so but this will be a function of the mechanisms that we 
insert in MPTCP.

> ·         If we can agree that the solution is based on a new MPTCP option

For this use case, given the mobility of the smartphone, it is unlikely 
that the Proxy will reside on path.
The key issue is the ability to signal addresses (mainly the server 
address) to the Proxy without adding delay to the connection 
establishment. This can be achieved by either :
- adding options to the SYN (but we have to cope with the limited size 
of the TCP options field in the MPTCP SYN)
- adding information in the payload of the SYN, this information would 
likely be encoded in a TLV format like the TCP/MPTCP options and should 
be compatible with the utilisation of TFO.

> ·         If any impact is already envisaged on the current MPTCP
> protocol’s semantics (other than the new option) eg in terms of
> https://tools.ietf.org/html/rfc6824#section-4

I don't think so. If we end up putting TLV information in the payload of 
the SYN, some parts of the SYN payload will not belong to the bytestream 
and this might affect the protocol semantics.
>
> ·         If any impact is already envisaged on TCP’s semantics, or any
> mods are needed, or assumptions about its behaviour, etc

I don't think so.

> ·         If any impact is already envisaged on other existing transport
> protocol’s semantics (presuming people still would like non-TCP in scope?)

I'm not personally convinced by the benefits of transporting an non 
bytestream transport protocol into TCP.

> ·         Anything else that you think is needed in order to frame the
> work item
>

The key requirement is that the creation of an MPTCP connection through 
a Proxy does not require additional rtts.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 11 Nov 2016 19:01:37 +0100

Phil,
> discussion is reaching some common understanding?

Please find some comments related to the dual-ended proxy Multipath TCP 
Proxy use case. In this use case, there are two proxies :
- an on-path upstream proxy that resides typically in the CPE
- a downstream proxy. This proxy may be on-path or off-path. My answers 
relate to the off-path proxy unless otherwise noted

> address of the ‘legacy’ host it wants to communicate with)

The scenario is a laptop that does not support MPTCP connected to a CPE 
and the CPE is itself connected to two access networks (typically xDSL 
and cellular). The upstream proxy is included in the CPE. The downstream 
CPE is typically installed inside the network of the access provider.

> protocol’s fallback behaviour and coping with middleboxes

I don't think so. If the proxies are deployed by a network operator, it 
is possible to ensure that there are no middleboxes that mess with MPTCP 
on the paths between the two proxies.

I don't think so.

> ·         Anything else that you think is needed in order to frame the

This use case is considered by various network operators. They are in a 
position to ensure that there is no middlebox between the two proxies. 
We should take this fact into account by designing a solution that is 
optimised for the case where there is no middlebox on the path. In this 
use case, there are a large number of MPTCP connections between the 
upstream and downstream proxies. We are not in the same situation as a 
host trying to establish a single MPTCP connection towards a random 
server over a random path. We should leverage this knowledge in our design.

As for the single-ended proxy, the key requirement is that the creation 
of an MPTCP connection through a Proxy does not require additional rtts.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Nov 2016 10:10:18 -0800

On 11/11/2016 10:01 AM, Olivier Bonaventure wrote:
> likely be encoded in a TLV format like the TCP/MPTCP options and
> should be compatible with the utilisation of TFO. 

> ...
>
> I don't think so. If we end up putting TLV information in the payload
> of the SYN, some parts of the SYN payload will not belong to the
> bytestream and this might affect the protocol semantics.

If you put options in the SYN payload, you don't have TCP anymore. TCP
allows the user to pick source and dest ports and addresses. There's no
way to fallback without resetting the pending SYN and that needs to be
followed by a wait (pref a TIME-WAIT equivalent). It's not TCP's
perogative to retry the connection with a new source port.

That was known when MPTCP was created. It was known when TCPM explored
the variety of alternatives to extending the SYN (including sending both
new and legacy SYNs at the same time, send a SYN and an "out of band"
message (EOS-SYN) and 4-way handshake). If you think you have an
approach that works, please review these docs (I'm updating EOS-SYN  and
the non-SYN EDO extension with more detail once the queue opens). Let's
not replicate that discussion here.

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 11 Nov 2016 21:08:19 +0100

Joe,
>> should be compatible with the utilisation of TFO.

With the words TLV-format, I wanted to report some of the suggestions 
made on the list, namely to explore the possiblity of placing the proxy 
information as a shim application that exchanged the proxy information 
inside the SYN and SYN+ACK and leaves all the other data for the normal 
bytestream. It might work, but I'd need some time to think about it in 
details.
> followed by a wait (pref a TIME-WAIT equivalent).

With the single-ended proxy, we are in a specific use case.

The application issues connect(server, port)

The stack does connect(proxy, port) and informs the proxy of the server 
address and port number. The proxy then connects the server and port.
Since the client will issue many connections towards this proxy, we can 
define a test to verify that there is no middlebox on the path between 
the client and the proxy (and fallback to regular TCP if a problem is 
detected).

If the SYN to the proxy fails, a possible fallback is to send a SYN 
directly to the server. This does not require any timewait since the 
connection is towards a different destination address.

 > It's not TCP's

I'm not suggesting that.
> not replicate that discussion here.

I've already read several versions of these docs and would be ready to 
read and review the next ones.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Nov 2016 12:21:56 -0800

On 11/11/2016 12:08 PM, Olivier Bonaventure wrote:
> made on the list, namely to explore the possiblity of placing the
> proxy information as a shim application that exchanged the proxy
> information inside the SYN and SYN+ACK and leaves all the other data
> for the normal bytestream. It might work, but I'd need some time to
> think about it in details.

This is not backward compatible with legacy TCP. All information in the
TCP SYN can be kept by the legacy server and can thus pollute the data
stream of the legacy connection. TCPM already explored this.

> The stack does connect(proxy, port) and informs the proxy of the
> server address and port number. The proxy then connects the server and
> port.
> Since the client will issue many connections towards this proxy, we
> can define a test to verify that there is no middlebox on the path
> between the client and the proxy (and fallback to regular TCP if a
> problem is detected).

None of this matters... what matters is the legacy.
> connection is towards a different destination address.

You're describing the behavior of an application (to TCP). The problem
is that you want to create a new TCP, one where an option that isn't
reflected in the SYN-ACK results in a failed connection. Having any
option have this property is (by definition) breaking backward
compatibility when that option is used.

The problem with such "MUST use" options is that there is no way to
*ensure* that this capability is used only by a particular application
for a particular use.

Joe

---

From: Alan Ford <[email-masked]>
Date: Mon, 14 Nov 2016 06:11:22 +0000

I think this work item is achievable by simply removing references to “at least one end” from the existing charter item on the proxy. So the item would now read:

Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful. For example, potentially helping MPTCP’s 
incremental deployment by allowing only one end host to be MPTCP-enabled 
and the middlebox acts as an MPTCP proxy for the other end host, which runs 
TCP; and potentially helping some mobility scenarios, where the middle box 
acts as an anchor between two MPTCP-enabled hosts. Alternatively, neither 
end host could be MPTCP-enabled but a pair of proxies could work together to 
bring MPTCP benefits to such connections. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues.

In some ways, the two ended proxy work could even be seen as an extension of the previous operational experience work within this WG.

Regards,
Alan

> On 10 Nov 2016, at 19:17, [email-masked] wrote:
> 
> Hi,
> We’re trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we’d assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we’d like discussion on these points to avoid getting into the fine details of one particular existing proposal.
>  
> What we’d appreciate is a summary of what the assumptions /understandings are about:
> ·         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the ‘legacy’ host it wants to communicate with)
> ·         If any impact is already envisaged on the current MPTCP protocol’s fallback behaviour and coping with middleboxes
> ·         If any impact is already envisaged on the current MPTCP protocol’s semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4 <https://tools.ietf.org/html/rfc6824#section-4>  
> ·         If any impact is already envisaged on TCP’s semantics, or any mods are needed, or assumptions about its behaviour, etc
> ·         If any impact is already envisaged on other existing transport protocol’s semantics (presuming people still would like non-TCP in scope?)
> ·         Anything else that you think is needed in order to frame the work item
>  
> This may seem like a long list, but most of the answers can be “none” – we’ll end up with just a short paragraph or a few bullets in the charter.
>  
> We’d also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.
>  
> Thanks
> Phil & Yoshi
> _______________________________________________
> multipathtcp mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 06:32:08 +0000

i think we should move beyond "exploring whether it would be useful".

i'd like us to assess proposed solutions. i think we should say this is what we're doing - at the moment we've had quite a lot of discussion about one proposal. we should give the chance for other proposals, and make the discussion more structured (what are the assessment criteria).

i also think we should explicitly exclude non-tcp traffic  (i think non-tcp traffic is too big a topic for our WG)

phil

________________________________
From: Alan Ford <[email-masked]>
Sent: 14 November 2016 06:11
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Regards,
Alan

On 10 Nov 2016, at 19:17, [email-masked]<mailto:[email-masked]> wrote:

Hi,

What we’d appreciate is a summary of what the assumptions /understandings are about:
•         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the ‘legacy’ host it wants to communicate with)
•         If any impact is already envisaged on the current MPTCP protocol’s fallback behaviour and coping with middleboxes
•         If we can agree that the solution is based on a new MPTCP option
•         If any impact is already envisaged on the current MPTCP protocol’s semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4
•         If any impact is already envisaged on TCP’s semantics, or any mods are needed, or assumptions about its behaviour, etc
•         If any impact is already envisaged on other existing transport protocol’s semantics (presuming people still would like non-TCP in scope?)
•         Anything else that you think is needed in order to frame the work item

Thanks
Phil & Yoshi
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 07:05:36 +0000

Hi Phil,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 10 novembre 2016 20:17
À : [email-masked]
Objet : [multipathtcp] Towards a Multipath TCP Proxy work item

Hi,

[Med] The main assumptions are:

·         The address(es) of the remote endpoint is/are retrieved using state of the art mechanisms; no change is required.

·         This work does not mandate nor preclude that a proxy is on a default forwarding path. Scenarios with host mobility are likely to require the address(es) of the proxy, though.

[Med] This work leverages on that behaviour (because this is MPTCP). Further, it requires a dedicated procedure for negotiating the support of the extension for the very FIRST connection to a given proxy.

[Med] I don't think there is an agreement on this but my current collection is as follows:

·         I heard that participants see benefits in 0-RTT MPTCP proxying

·         I didn't hear objecting to insert data in SYN

·         I do personally think that the negotiation of the extension (SYN/AYN-ACK) allows for a safe use on the Internet without violating any of TCP/MPTCP specs.

·         I know Joe still has an issue with this to be defined as a TCP option.

I don't think that we MUST have a consensus on this before chartering this work. I agree this is simple if we have such an agreement, but IMHO it is just fair to leave the final decision for after-charter work.

[Med] I do think we can do this work without such modification, but this is typically the kind of decisions we can reach once the work item is chartered, not before.

[Med] I don't expect any modification to TCP/

[Med] There is no expected modification. I do think that handling other protocols will be valuable because this will avoid having a solution for each transport protocols (UDP, namely.

[Med] I would like to add explicit items for DHCP and RADIUS extensions.

Thanks
Phil & Yoshi

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 07:14:15 +0000

something it would be good to have discussion about.

We could restrict to where both proxies are under the control of the same operator. I think this matches the current deployments, and it would simplify the security and config

________________________________
From: multipathtcp <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 14 November 2016 06:32
To: [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 14 Nov 2016 07:30:14 +0000

I agree we should document how proxies (single/dual ended) should behave in conjunction with MPTCP.
It is particularly important they don’t interfere with E2E MPTCP flows, etc.

So in essence I support adding this in the charter and document the scenario’s and the behaviour of the proxies

From: multipathtcp <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, 14 November 2016 at 15:32
To: Alan Ford <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 14 Nov 2016 08:33:56 +0100

Phil,

> We could restrict to where both proxies are under the control of the
> same operator. I think this matches the current deployments, and it
> would simplify the security and config
>

For the two-ended proxies, I agree that in current deployments the same 
operator controls both proxies.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 14 Nov 2016 08:36:16 +0100

Phil,

> i'd like us to assess proposed solutions. i think we should say this is
> what we're doing - at the moment we've had quite a lot of discussion
> about one proposal. we should give the chance for other proposals,
> and make the discussion more structured (what are the assessment
> criteria).
>

Totally agree. Let's ask for proposals described in drafts at the next 
IETF meeting and decide based on detailed documents and not based on a 
few sentences exchanged by email. Details matter

Olivier

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 14 Nov 2016 07:37:35 +0000

Indeed dual ended proxies are typically controlled by a single operator.

On 14/11/2016, 16:33, "multipathtcp on behalf of Olivier Bonaventure" <[email-masked] on behalf of [email-masked]> wrote:

    Phil,

    
    Olivier
    
    [email-masked]

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 07:37:32 +0000

Hi,

yes, that seems to be a valid assumption. Doing this in a multi-operator environment can be quite complex.

Regards

Nic

Von: multipathtcp [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Montag, 14. November 2016 08:14
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

________________________________
From: multipathtcp <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 14 November 2016 06:32
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

________________________________
From: Alan Ford <[email-masked]<mailto:[email-masked]>>
Sent: 14 November 2016 06:11
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

I think this work item is achievable by simply removing references to "at least one end" from the existing charter item on the proxy. So the item would now read:

middlebox would be useful. For example, potentially helping MPTCP's

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: David Allan I <[email-masked]>
Date: Mon, 14 Nov 2016 07:39:21 +0000

That is the scenario the BBF work is focused on...

Cheers
Dave

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE)
Sent: Monday, November 14, 2016 4:38 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

    Phil,

    
    Olivier

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 07:55:37 +0000

Hi Phil,

If you meant that the access networks are managed by the same operators, then this is indeed a valid deployment model to start with.

BTW, this model is similar whether this implies single or dual ended proxies:

·         For the single proxy: the operator provisions the host and manages the proxy located in the network.

·         For the dual proxy: The operator provisions the CPE and manages the proxy located in the network.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 14 novembre 2016 08:14
À : [email-masked]
Cc : [email-masked]
Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: <[email-masked]>
Date: Tue, 15 Nov 2016 07:57:48 +0000

Phil,

If you feel it would take too long and to be too complex to achieve in a reasonable timeframe, we are ok with excluding non-tcp traffic, however, for our total solution we do requires also non-tcp traffic to be sent over multiple paths. We could argue that we can use a different mechanisms specifically for UDP and other protocols, but it would be nice to have as single MPTCP-based solution. (my gut feeling is that we would need to replicate a lot of MPTCP scheduling features into a new mechanism).

Marcus

Von: multipathtcp <[email-masked]> im Auftrag von "[email-masked]" <[email-masked]>
Datum: Montag, 14. November 2016 um 07:32
An: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: <[email-masked]>
Date: Tue, 15 Nov 2016 08:56:57 +0000

Hi Markus, all,

I’m on the same page that non-tcp traffic should be considered in scope. At least, the UDP case should be investigated. I remember there was interest in BA meeting about the UDP part (https://www.ietf.org/proceedings/95/minutes/minutes-95-mptcp).

An option I see is to consider advancing the use of MPTCP to convey UDP flows in a separate EXPERIMENTAL specification that will be cross-reviewed with other WGs (intarea, tsvwg). Having that base specification will help having interoperable implementations that will be used to carry experimentations.

Those experiments will help to determine whether the proposed solution is complex/simple, viable/non-viable, failed/successful, etc.

Let’s give it a try.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 15 novembre 2016 08:58
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Phil,

Marcus

Von: multipathtcp <[email-masked]<mailto:[email-masked]>> im Auftrag von "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Datum: Montag, 14. November 2016 um 07:32
An: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi

---

From: Robert Skog <[email-masked]>
Date: Tue, 15 Nov 2016 10:08:52 +0000

+1
We see a need to solve UDP in several places, so having a separate specification can help this moving forward.

Cheers,
/Robert

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: den 15 november 2016 09:57
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Hi Markus, all,

Let’s give it a try.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mardi 15 novembre 2016 08:58
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Phil,

Marcus

phil

Regards,
Alan

Hi,

Thanks
Phil & Yoshi