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

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 14:13:15 +0000

On 31/07/16 23:02, "multipathtcp on behalf of Rao Shoaib" <[email-masked] on behalf of [email-masked]> wrote:

>
>
>On 07/27/2016 01:43 AM, Olivier Bonaventure wrote:
>> Phil,
>>
>>> So far this discussion has made me a bit confused. Let me ask a specific
>>> question:-
>>>
>>> Why do we need both transparent and plain mode? If these are addressing
>>> different usage scenarios, please explain them (in a paragraph?)
>>
>> The two modes address different deployment scenarios.
>>
>> In the transparent mode, the HAG resides on the path to/from the 
>> client. There are many ways in current networks to ensure that the HAG 
>> is on the path of the clients that it serves. The transparent mode 
>> requires one option to distinguish between end-to-end MPTCP 
>> connections (directly established by the client using an MPTCP stack) 
>> and proxied connections. During IETF96, the authors of plain-mode and 
>> transparent-mode agreed that the transparent-mode draft would use an 
>> emply plain mode option to indicate that a connection has been proxied.
>Why is it necessary to know that the connection has been proxied ?

WH> Otherwise the concentrator will perform the proxy function although the destination is the application server.
So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act upon MPTCP flow that should be proxied in network assisted mode. This is the reason we need an indication about this
>>
>> In the plain-mode, the HAG does not need to be on the path to/from the 
>> client. The plain-mode option is used to signal the original 
>> source/destination address of the connection depending on the usage.
>Since we seem to be only considering TCP, will the protocol field be 
>removed from the draft ?

WH> this is to be discussed 
>
>Shoaib
>>
>>
>>
>>
>> Olivier
>>
>> _______________________________________________
>> multipathtcp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>_______________________________________________
>multipathtcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Mon, 1 Aug 2016 15:45:57 +0000

Thanks.
So, for text for a potential work item, we could say something like "the WG assumes that the HAG is not necessarily on the default routing path between the end hosts".  This then leaves open whether we solve this problem in the mptcp-based protocol (as per plain mode) or solve it in the underlying layer (eg through a tunnel - transparent mode).
Do we assume that the other end of the mptcp segment is on the default routing path?  I suppose this is the case for the CPE example we usually have in mind - but since we want a general protocol, it would be good if this end also need not be on the default end-to-end path. 

It was also suggested to have a second (informational) document.
As a point of reference, our charter currently says (this is about one-ended proxy): << 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.>>
So a potential work item may say something like:
The working group will detail the use cases /deployment scenarios, the operational considerations and .... [anything else? Interaction with endhost-to-endhost MPTCP?]

Incidentally, it may be possible to use some of the text from draft-deng-mptcp-mobile-network-proxy ?

I also note that draft-boucadair-mptcp-plain-mode has a very open-ended ipr statement. Do you think it could be made more specific (at some point)? 

phil

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: 27 July 2016 09:43
To: Eardley,PL,Philip,TUB8 R <[email-masked]>; [email-masked]
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Phil,

> Why do we need both transparent and plain mode? If these are 
> addressing different usage scenarios, please explain them (in a 
> paragraph?)

In the transparent mode, the HAG resides on the path to/from the client. 
There are many ways in current networks to ensure that the HAG is on the path of the clients that it serves. The transparent mode requires one option to distinguish between end-to-end MPTCP connections (directly established by the client using an MPTCP stack) and proxied connections. 
During IETF96, the authors of plain-mode and transparent-mode agreed that the transparent-mode draft would use an emply plain mode option to indicate that a connection has been proxied.

In the plain-mode, the HAG does not need to be on the path to/from the client. The plain-mode option is used to signal the original source/destination address of the connection depending on the usage.

Olivier

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 1 Aug 2016 11:42:48 -0700

> So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act up…
This seems like a deployment issue not a protocol issue. The decision to 
proxy or not proxy should be based on the IP addresses or out of band 
signaling. After all the entity adding the option some how knows to add 
the option.

I liked the initial proposal as it did not require any changes to the 
protocol. These change (as I have said before) seem very deployment 
specific and IMHO should not be part of the protocol.
> WH> this is to be discussed
It has to be or we are allowing protocol encapsulation. In which case we 
need to define the complete mechanism.

Rao

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 1 Aug 2016 11:50:34 -0700

I do not understand why TCP is in scope and any other protocol is not. 
At the Yokohama IETF most in the room were interested in encapsulating 
UDP. In fact encapsulating TCP has more implications (due to its end to 
end congestion control) than UDP and hence that needs to be studied.

A compromise could be that we define a generic option that means, 
interpret the header enclosed or some thing like that. It's too bad that 
the mobile environment can not deal with the extra header. In which case 
it should always use transparent proxying.

Rao.

On 07/26/2016 08:07 AM, [email-masked] wrote:
>
> So far this discussion has made me a bit confused. Let me ask a 
> specific question:-
>
> paragraph?)  (this is important as a charter item would start by 
> talking about the issue it was tackling – and then may mention some 
> starting points or assumptions about the solution)
>
> Plain mode involves a signalling protocol (extension to mptcp – I 
> assume this would be in scope of a prospective charter); then 
> subsequently a way of handling the actual traffic (UDP seems out of 
> scope; TCP I’m not sure to what extent this would be in scope). Do I 
> understand this right? Comments?
>
> Thanks
>
> phil
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 19:05:22 +0000

>specific and IMHO should not be part of the protocol.
WH> I would disagree since you don’t always control the addressing and it is better to have an explicit signaling in the protocol what to expect to happen.
>need to define the complete mechanism.
WH> I would agree to that

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 1 Aug 2016 12:46:09 -0700

> WH> I would disagree since you don’t always control the addressing and it is better to have an explicit signaling in the protocol what to expect to happen.
Can you kindly provide an example of another standard IETF protocol that 
has this feature or something similar.

Shoaib

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 20:40:29 +0000

From: Rao Shoaib <[email-masked]<mailto:[email-masked]>>
Date: Monday 1 August 2016 at 21:46
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Can you kindly provide an example of another standard IETF protocol that has this feature or something similar.

WH> I am not sure how relevant this is but you can find them in SIP e.g. Let have the discussion on th requirements. We already indicated that the usage of SOCKS is too chatty which is an OOB mechanism we propose. In the scenario’s we have in mind it is better to do this in-band in the protocol to avoid the extra latency.

Shoaib

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 1 Aug 2016 13:43:18 -0700

On 08/01/2016 01:40 PM, Henderickx, Wim (Nokia - BE) wrote:
>
>
> From: Rao Shoaib <[email-masked] <mailto:[email-masked]>>
> To: Wim Henderickx <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> Can you kindly provide an example of another standard IETF protocol 
> that has this feature or something similar.
>
> WH> I am not sure how relevant this is but you can find them in SIP 
> e.g. Let have the discussion on th requirements. We already indicated 
> that the usage of SOCKS is too chatty which is an OOB mechanism we 
> propose. In the scenario’s we have in mind it is better to do this 
> in-band in the protocol to avoid the extra latency.
Sounds good.

Shoaib

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 20:44:43 +0000

>Do we assume that the other end of the mptcp segment is on the default routing path?  I suppose this is the case for the CPE example we usually have in mind - but since we want a general protocol, i…

WH> we should not assume the proxy is on the default path since it limits a number of use cases
>The working group will detail the use cases /deployment scenarios, the operational considerations and .... [anything else? Interaction with endhost-to-endhost MPTCP?]
WH> I would think: use cases/deployment scenarios, protocol extensions for the proxy
Interaction with end-host MPTCP should be covered in the use case/deployment scenario
>Incidentally, it may be possible to use some of the text from draft-deng-mptcp-mobile-network-proxy ?

WH> we could use some text but it is mobile centric
>> specific

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 1 Aug 2016 21:05:21 -0700

Hello,

On Mon, Aug 1, 2016 at 1:40 PM, Henderickx, Wim (Nokia - BE) <
[email-masked]> wrote:

>
>
> From: Rao Shoaib <[email-masked]>
> To: Wim Henderickx <[email-masked]>, "[email-masked]" <
> [email-masked]>
> I liked the initial proposal as it did not require any changes to the >protocol. These change (as I have said before) seem very deployment >specific and IMHO should not be part of the protocol.
>
> WH> I am not sure how relevant this is but you can find them in SIP e.g.
> Let have the discussion on th requirements. We already indicated that the
> usage of SOCKS is too chatty which is an OOB mechanism we propose. In the
> scenario’s we have in mind it is better to do this in-band in the protocol
> to avoid the extra latency.
>

I personally think this could be a trade-off discussion point.
A question would be if we want to update mptcp to carry non-mptcp-related
(upper layer) info into the mptcp option in order to reduce latency for
specific use cases.

Or, we just use mptcp as it is and accept the latency. SOCKS might be too
chatty for this purpose, but I am thinking it will not be an only option.

Thanks,
--
Yoshi

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 2 Aug 2016 04:08:08 +0000

From: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 2 August 2016 at 06:05
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Rao Shoaib <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hello,

On Mon, Aug 1, 2016 at 1:40 PM, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

I personally think this could be a trade-off discussion point.
A question would be if we want to update mptcp to carry non-mptcp-related (upper layer) info into the mptcp option in order to reduce latency for specific use cases.

Or, we just use mptcp as it is and accept the latency. SOCKS might be too chatty for this purpose, but I am thinking it will not be an only option.

WH> we are discussing it. If there is a clear advantage of extending this in the protocol I don’t see why we shouldn’t agree to such solution of embedding it in the protocol.

Thanks,
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 1 Aug 2016 21:15:21 -0700

Hello,

> WH> I would agree to that

Just in case, I might want to clarify this won't be encapsulation since I
think what plain-mode does is protocol conversion.
My concern is protocol conversions between mptcp-tcp and mptcp-udp might be
very different. Also, if we try to support other protocols, we might need
other conversion rules.

Thanks,
--
Yoshi

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 2 Aug 2016 04:17:50 +0000

Date: Tuesday 2 August 2016 at 06:15

Hello,

Just in case, I might want to clarify this won't be encapsulation since I think what plain-mode does is protocol conversion.
My concern is protocol conversions between mptcp-tcp and mptcp-udp might be very different. Also, if we try to support other protocols, we might need other conversion rules.

WH> or we can call it protocol mapping or so.

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Tue, 2 Aug 2016 06:33:41 +0000

Hi Phil,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 1 août 2016 17:46
> À : [email-masked]
> Objet : Re: [multipathtcp] towards a potential work item on two-ended
> proxy
> 
> Thanks.
> So, for text for a potential work item, we could say something like "the
> WG assumes that the HAG is not necessarily on the default routing path
> between the end hosts".

[Med] Yes, with some modifications to the wording: 
* Actually, there are many "default" forwarding path*S*; a default forwarding path per network attachment. These default forwarding paths may be completely disjoint. 
* I suggest to avoid using "HAG" term because it is tied to a specific use case while the proxy work is applicable to a variety of use cases. I prefer much more "MPTCP Concentrator" or "Network-Assisted MPTCP Proxy".  

  This then leaves open whether we solve this
> problem in the mptcp-based protocol (as per plain mode) or solve it in the
> underlying layer (eg through a tunnel - transparent mode).
> Do we assume that the other end of the mptcp segment is on the default
> routing path?  I suppose this is the case for the CPE example we usually
> have in mind - but since we want a general protocol, it would be good if
> this end also need not be on the default end-to-end path.

[Med] Another approach for this one is the charter to be silent about it, i.e., we don't assume nor preclude it.       

> As a point of reference, our charter currently says (this is about one-
> ended proxy): << 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.>>
> The working group will detail the use cases /deployment scenarios, the
> operational considerations and .... [anything else? Interaction with
> endhost-to-endhost MPTCP?]

[Med] I would add protocol extensions to differentiate native MPTCP connections from proxied ones. 

> I also note that draft-boucadair-mptcp-plain-mode has a very open-ended
> ipr statement. Do you think it could be made more specific (at some
> point)?

[Med] FWIW, that IPR does not apply to the current version of the plain-mode draft since a step mentioned in the first claim of that patent deposit is not present in the draft.  

> There are many ways in current networks to ensure that the HAG is on the
> path of the clients that it serves. The transparent mode requires one
> option to distinguish between end-to-end MPTCP connections (directly
> established by the client using an MPTCP stack) and proxied connections.
> During IETF96, the authors of plain-mode and transparent-mode agreed that
> the transparent-mode draft would use an emply plain mode option to
> indicate that a connection has been proxied.
>

---

From: Alan Ford <[email-masked]>
Date: Tue, 2 Aug 2016 14:52:32 +0100

Hi all,

> On 1 Aug 2016, at 20:05, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:

I’m trying to distinguish the various use cases; can we confirm this is correct?

Transparent Mode
- Source address = real source address
- Destination address = real destination address
- Transparent proxies create MPTCP functionality in the stream, adding and removing the MPTCP headers, mapping seq numa, etc
- Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it

Plain Mode
- Source address = real source
- Destination address = proxy destination address
- Signalling protocol inside indicates real destination address

So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?

The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Proxy from Operator A, but in fact is picked up by Operator B.

As I’ve said before, the plain mode option is not MPTCP-specific and is simple a signal that says “everything that follows is actually targeted for IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could know where to find a proxy (e.g. a well-known anycast address) then addresses could be rewritten and packets forwarded, with no need for any MPTCP protocol changes.

However, I fear I may be misunderstanding some of the elements here, so I look forward to a consolidated draft where it should hopefully be much clearer what the proposal is.

Regards,
Alan

---

From: <[email-masked]>
Date: Tue, 2 Aug 2016 14:48:22 +0000

That's not quite what I meant.
I was referring to defining a new tunnelling protocol or "swapping the headers" protocol or something similar. I think this is not something that mptcp wg would standardise - at least, I think we would have to liaise with other WGs (Intarea wg) about this - as it would seem more in their remit than ours. If this is something that we know in advance the proxy work will require (rather than something that may emerge when we develop the solution), then we probably should start the discussion sooner than later

phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of Rao Shoaib
Sent: 01 August 2016 19:51
To: [email-masked]
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

I do not understand why TCP is in scope and any other protocol is not. At the Yokohama IETF most in the room were interested in encapsulating UDP. In fact encapsulating TCP has more implications (due to its end to end congestion control) than UDP and hence that needs to be studied.

A compromise could be that we define a generic option that means, interpret the header enclosed or some thing like that. It's too bad that the mobile environment can not deal with the extra header. In which case it should always use transparent proxying.

Rao.
On 07/26/2016 08:07 AM, [email-masked]<mailto:[email-masked]> wrote:
So far this discussion has made me a bit confused. Let me ask a specific question:-
Why do we need both transparent and plain mode? If these are addressing different usage scenarios, please explain them (in a paragraph?)  (this is important as a charter item would start by talking about the issue it was tackling - and then may mention some starting points or assumptions about the solution)
Plain mode involves a signalling protocol (extension to mptcp - I assume this would be in scope of a prospective charter); then subsequently a way of handling the actual traffic (UDP seems out of scope; TCP I'm not sure to what extent this would be in scope). Do I understand this right? Comments?
Thanks
phil

---

From: <[email-masked]>
Date: Tue, 2 Aug 2016 14:55:23 +0000

>... So a potential work item may say something like:
WH> I would think: use cases/deployment scenarios, protocol extensions 
WH> for the proxy
> Interaction with end-host MPTCP should be covered in the use case/deployment scenario

Phil:
What are the interactions with endhost-to-endhost MPTCP?  I imagined there wouldn’t be any, but it sounds like there are some. 

Thanks
phil

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 2 Aug 2016 17:48:56 +0000

>What are the interactions with endhost-to-endhost MPTCP?  I imagined there wouldn’t be any, but it sounds like there are some.

WH> there should be none, but the proxy should ensure he doesn’t touch it. Hence we are looking to understand if a dual ended proxy should  perform a proxy function or not. So the end-host is not impacted but the network-assisted proxies would be made aware what to do. Make sense?

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 2 Aug 2016 19:11:12 +0000

>- Source address = real source address
WH> not always since NAT can be in the path
>- Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it
WH> indeed or not intercept it based on the indication
>- Source address = real source
WH> could also be NATed in some use cases
>- Signalling protocol inside indicates real destination address
WH> or SRC address
>So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?
WH> the main difference is mainly DST IP is changed to get explicit routing to the proxy versus being implicit in the transparent case
>The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Pro…
WH> the network assisted proxy is mainly targeting single operator/controlled operator use cases to avoid these issues.
>As I’ve said before, the plain mode option is not MPTCP-specific and is simple a signal that says “everything that follows is actually targeted for IP address a.b.c.d” - this is entirely transport-a…
WH> you would still need to know the original destination IP@ that the application wanted to go to.
>However, I fear I may be misunderstanding some of the elements here, so I look forward to a consolidated draft where it should hopefully be much clearer what the proposal is.
WH> hope some answers clarify

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 2 Aug 2016 19:31:56 +0000

>* I suggest to avoid using "HAG" term because it is tied to a specific use case while the proxy work is applicable to a variety of use cases. I prefer much more "MPTCP Concentrator" or "Network-Assi…

WH> Indeed Network-assisted MPTCP proxy seems like a good terminology
>[Med] Another approach for this one is the charter to be silent about it, i.e., we don't assume nor preclude it.  
WH> agreed, we should have the charter focus on single ended MP-TCP and network assisted MP-TCP proxies e.g.
>[Med] I would add protocol extensions to differentiate native MPTCP connections from proxied ones.
WH> agreed

---

From: Alan Ford <[email-masked]>
Date: Wed, 3 Aug 2016 08:20:26 +0100

Hi Wim, all,

Comment inline...

> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:
> On 02/08/16 15:52, "Alan Ford" <[email-masked] <mailto:[email-masked]>> wrote:
> 

OK, so my understanding appears correct here.

> WH> you would still need to know the original destination IP@ that the application wanted to go to.

Which is the point of the signalling protocol - the proposed “plain mode option” which is actually carried in the payload. My issue with this is that this is _not MPTCP-specific_. This is simply a signal above the transport layer to inform a proxy what the real destination is.

Regards,
Alan

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Wed, 3 Aug 2016 18:58:10 +0000

Alan, in-line

From: Alan Ford <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 3 August 2016 at 09:20
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Rao Shoaib <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Wim, all,

Comment inline...

On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:
On 02/08/16 15:52, "Alan Ford" <[email-masked]<mailto:[email-masked]>> wrote:

Transparent Mode

Plain Mode

WH> yes

WH> I hear, you and I understand but we have an explicit use case for this with MPTCP and so far not in any other protocol. Hence I think it is good to extend MPTCP with this capability and liase with other WG(s) about this.

Regards,
Alan

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 03 Aug 2016 17:10:09 -0700

> On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:
> 
> Alan, in-line
> 
> From: Alan Ford <[email-masked] <mailto:[email-masked]>>
> To: Wim Henderickx <[email-masked] <mailto:[email-masked]>>
> Cc: Rao Shoaib <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <[email-masked] <mailto:[email-masked]>> wrote:

While you may have a use-case for having proxies work with your MPTCP solution, it does not directly follow that the MPTCP protocol or WG is the best place to specify how the proxy works. This really does seem like a proxy solution that can be made more generic, and at the very least belongs as a protocol that is run within the MPTCP stream. This is what the SOCKS protocol does, and there is no reason you can't run SOCKS over MPTCP, or create a new variant of SOCKS or a similar protocol that you will run on top of MPTCP for your solution. Indeed, it could be seen as a benefit to work on the proxying solution independently from MPTCP, since that way it can be used for other transports. The end result will be the same, and the architecture will be cleaner.

Best,
Tommy Pauly

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Thu, 4 Aug 2016 04:14:13 +0000

inline

From: <[email-masked]<mailto:[email-masked]>> on behalf of Tommy Pauly <[email-masked]<mailto:[email-masked]>>
Date: Thursday 4 August 2016 at 02:10
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Alan Ford <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

WH> given the extension is specific in TCP?MPTCP since we carry the information in a SYN packet it becomes specific to the protocol and hence I still believe it fits. Other transport mechanisms have other means and can adopt a similar information element but the way the protocol consumes it is specific and should be done in the protocol afais.

Best,
Tommy Pauly

Regards,
Alan

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

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 03 Aug 2016 21:32:46 -0700

Hello,

> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:
> From: <[email-masked] <mailto:[email-masked]>> on behalf of Tommy Pauly <[email-masked] <mailto:[email-masked]>>
> Cc: Alan Ford <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Alan, in-line
>> 
> WH> given the extension is specific in TCP?MPTCP since we carry the information in a SYN packet it becomes specific to the protocol and hence I still believe it fits.

The information is actually carried in the payload. So, it is not really part of TCP/MPTCP. Carrying it in the SYN is just because TCP does not prevent carrying data in the SYN-segment.

> Other transport mechanisms have other means and can adopt a similar information element but the way the protocol consumes it is specific and should be done in the protocol afais.

I disagree that the information is consumed by MPTCP. It is rather consumed by the application sitting right on top of MPTCP, because this is the one that is reading the data out of the MPTCP-stream and forwarding it over to final destination. And MPTCP itself is not really using the plain-mode option.

If you look at Socks v4, it is actually carrying the exact same information than the plain-mode option (besides the protocol-field). So, an implementation could easily put the Socks-client request in the SYN-payload. The proxy who receives that can then (after connecting to the final server) reply in the SYN/ACK with the Socks-server option in the SYN/ACK's payload. And from there on, the data will be forwarded from one side to the other.

This would be a low-overhead handshake for the proxy without the chatty overhead of Socks v5.

Cheers,
Christoph

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 05:53:18 +0000

Hi Alan,

Please see inline.

Cheers,
Med

> Alan Ford
> Envoyé : mardi 2 août 2016 15:53
> À : Henderickx, Wim (Nokia - BE)
> Cc : [email-masked]
> >>> WH> Otherwise the concentrator will perform the proxy function
> although the destination is the application server.
> >>> So assume an E2E MPTCP flow. The UE initiates it and the element with
> the network assisted MPTCP proxy (Concentrator) receives it. The
> concentrator should not proxy this flow. It should only act upon MPTCP
> flow that should be proxied in network assisted mode. This is the reason
> we need an indication about this
> > WH> I would disagree since you don’t always control the addressing and
> it is better to have an explicit signaling in the protocol what to expect
> to happen.
> 
[Med] I would say, the transparent mode does not touch to the source IP address of the initial subflow. The source address of secondary subflows will be rewritten to be the same as for the initial subflow.  

> - Destination address = real destination address
[Med] This is only true for the first subflow. Subsequent subflows are sent with a destination address of the MPTCP proxy. This is the same as in the plain mode.

> - Transparent proxies create MPTCP functionality in the stream, adding and
> removing the MPTCP headers, mapping seq numa, etc
[Med] Yes, for all subflows.

> - Signalling protocol inside indicates real destination address
[Med] and the source address if source address preservation is required (e.g., IPv6).

> 
> So - please correct me if this is wrong - but the main difference is that
> Plain Mode is targeted towards a proxy server whereas the transparent mode
> does not change src/dst addresses?
[Med] No, see above. A major difference is how the first subflow is established and how a state is built in the MPTPC proxy. The plain mode can operate in both transparent mode (that is preserve an IP address of the CPE/host) or not. Configuration parameters are available to instruct the MPTCP behavior, e.g.,
* preserve the source IP address
* preserve the initial subflow IP address
* N:1 address rewriting
* 1:1 address rewriting
*..

The plain mode as currently written allows to provide: IPv4 bonding over IPv6-only networks, IPv6 bonding over IPvx networks, etc.

> 
> The issue I see with a generic proxy bit is that it does not contain any
> context about what kind of proxy is being intercepted. You could be
> sending in good faith expecting it to be picked up by Proxy from Operator
> A, but in fact is picked up by Operator B.

[Med] The use cases we are targeting assumes these networks are managed by the same operator. 

> 
> As I’ve said before, the plain mode option is not MPTCP-specific and is
> simple a signal that says “everything that follows is actually targeted
> for IP address a.b.c.d” - this is entirely transport-agnostic.

[Med] The plain mode allows for example to distinguish between native and proxied MPTCP connection. 
I'm puzzled here since MPTCP allows to inform a remote peer about an IP address while this is not TCP-specific. Isn't that information transport-agnostic as per you argument? (not mine).

 If the HAG
> could know where to find a proxy (e.g. a well-known anycast address) then
> addresses could be rewritten and packets forwarded, with no need for any
> MPTCP protocol changes.

[Med] You need the information about the ultimate destination IP address...and other information such as the source IP address for cases such as IPv4 bonding over IPv6 networks (IPv6-only networks is now a reality in mobile networks).

> 
> However, I fear I may be misunderstanding some of the elements here, so I
> look forward to a consolidated draft where it should hopefully be much
> clearer what the proposal is.
> 
> Regards,
> Alan
>

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 06:22:34 +0000

Dear Tommy,

The problem we have is how to glue multiple TCP connections established among multiple access networks while avoiding making any assumptions about the capabilities of end-users terminals and remote servers: This is a ** multipath TCP ** problem that we called “Network-assisted MPTCP”.

In addition to that problem, we have additional requirements such as:

·         Avoid extra delay to establish TCP sessions among multiple access networks compared to legacy TCP connections.

·         Optimize the load on the network-assisted Proxy (avoid chatty protocols, in particular)

·         Avoid interfering with native MPTCP connections.

·         Have one solution for both IPv4 and IPv6 + Do not make any assumption about the addressing scheme of available network attachment

·         …

Our MPTCP solution to this MPTCP problem is to define a dedicated MPTCP option.

We have investigated various tracks but we believe the MPTCP option is the right MPTCP solution to our MPTCP problem, e.g.,

·         One can optimize SOCKS to reduce the amount of exchanges, but still this out-of-band signaling and at least one RTT will be required to create a new MPTCP connection.

·         One can define an IP option to carry the information we have in the plain-mode but as you know “IP Options are not an option”!

·         One can define an IPv6 Extension Header but this extension imposes certain addressing schemes on access networks. This is not a starting point.

·         One can define an SDP extension but this is specific to that application: https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03

FWIW, the charter of the MPTCP WG already cites the proxy work.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Tommy Pauly
Envoyé : jeudi 4 août 2016 02:10
À : Henderickx, Wim (Nokia - BE)
Cc : [email-masked]
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

Best,
Tommy Pauly

Regards,
Alan

---

From: Alan Ford <[email-masked]>
Date: Thu, 4 Aug 2016 09:06:10 +0100

Hi Med,

> On 4 Aug 2016, at 06:53, <[email-masked]> <[email-masked]> wrote:
> 

I don’t get this argument… You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.

Your MPTCP proxy leverages MPTCP in order to apply new IP addresses to an existing MPTCP connection, which is great, but does not require any protocol extensions to do this. The only additional information it needs is the target, in the initial subflow, and this is provided by information in the payload.

This information is carried in the payload, and does not carry any information which is specific to MPTCP.

To be clear on this - I am not opposed to doing this work, and indeed I would be entirely happy to see the charter clarified to support work on two-ended proxies. This is valuable work. But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies” … If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be), that work should be done somewhere like intarea or tsvarea and referenced by this work.

Regards,
Alan

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 11:49:24 +0000

Re-,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:[email-masked]]
Envoyé : jeudi 4 août 2016 10:06
À : BOUCADAIR Mohamed IMT/OLN
Cc : Henderickx, Wim (Nokia - BE); [email-masked]
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

Hi Med,

On 4 Aug 2016, at 06:53, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

I don’t get this argument…
[Med] My point is about “transport-agnostic” part of your comment. One would argue that communication an IP address in a TCP option (which MPTCP is doing) is also “transport-agnostic” but no one is objecting to define such (MP)TCP option.

You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.
[Med] The PM option is in the payload because of the limited option space. In early versions of the draft, the option can be inserted in the dedicated TCP option space if there is enough space, payload, etc. but we abandoned that design to simply the implementations.

Your MPTCP proxy leverages MPTCP in order to apply new IP addresses to an existing MPTCP connection, which is great, but does not require any protocol extensions to do this. The only additional information it needs is the target, in the initial subflow, and this is provided by information in the payload.
[Med] It is in the payload because of the limited space and because of the lack of mature proposals to extend the SYN option space.

This information is carried in the payload, and does not carry any information which is specific to MPTCP.
[Med] It is specific to MPTCP as it allows, in addition to conveying a target/source IP address, to avoid interfering with native MPTCP connections. Also, the option allows to offload the MPTCP concentrator from the path if both endpoints are MPTCP-capable. All these aspects are specific to MPTCP.

To be clear on this - I am not opposed to doing this work, and indeed I would be entirely happy to see the charter clarified to support work on two-ended proxies. This is valuable work.
[Med] Ok. Let’s then agree on the charter update.

But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies”
[Med] That should be part of the work, indeed. But there are other aspects that are important such as avoiding interfering with native MPTCP connections, offload an MPTCP proxy from the path if both endpoints are MPTCP-capable, avoid extra delays to establish network assisted MPTCP connections, etc.

… If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be),
[Med] I still disagree here. The proposal we have on the table is specific to MPTCP.

that work should be done somewhere like intarea or tsvarea and referenced by this work.

Regards,
Alan

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 12:00:56 +0000

Thanks Med for the nice summary of requirements and the problems we have with a SOCKS+MPTCP combination. And yes we looked into many different ways of doing this, and so far MPTCP covers the largest set of requiremnts, except the problems you mentioned, therefore we are looking forward for a fix of those.

Marcus

Von: multipathtcp <[email-masked]> im Auftrag von "[email-masked]" <[email-masked]>
Datum: Donnerstag, 4. August 2016 um 08:22
An: Tommy Pauly <[email-masked]>, "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [multipathtcp] towards a potential work item on two-ended proxy

Dear Tommy,

·         …

Cheers,
Med

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

Best,
Tommy Pauly

Regards,
Alan

---

From: Alan Ford <[email-masked]>
Date: Thu, 4 Aug 2016 13:33:23 +0100

Hi Med,

Inline...

> De : Alan Ford [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : Henderickx, Wim (Nokia - BE); [email-masked] <mailto:[email-masked]>

No, it is not transport-agnostic, it is integral to how MPTCP operates.

> [Med] The PM option is in the payload because of the limited option space. In early versions of the draft, the option can be inserted in the dedicated TCP option space if there is enough space, pay…

But this information doesn’t need to be read or understood by a MPTCP stack!

It is telling the proxy application, which sits above MPTCP, where to forward the following payload data to.

This signal is a protocol which is not specific to MPTCP, and is in no way integrated with the rest of the MPTCP protocol.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows. This is all standard MPTCP behaviour and does not require any additional signalling.

> [Med] It is specific to MPTCP as it allows, in addition to conveying a target/source IP address, to avoid interfering with native MPTCP connections. Also, the option allows to offload the MPTCP con…

I agree that something would be needed at a higher-layer for a true transparent proxy implementation, since it needs to know which traffic to intercept and which to let through. However, this does not necessarily need to be at the MPTCP layer. IP Router Alert Option is one alternative possibility here (RFCs 2113 / 2711) - given this is proposed for use in a controlled network, I would hope that deployment issues for RAO are not of such a concern here.

For plain mode where an explicit proxy address is given, there is no need for any network alert, since the packets will either be addressed to the proxy, or they won’t.

> [Med] I still disagree here. The proposal we have on the table is specific to MPTCP.

Your proposal uses MPTCP as a multipath transport, however the protocol you have specified for signalling target address is not an MPTCP extension, it is a separate protocol.

However, we are arguing over a non-existent proposal right now. At IETF96 it was said a combined draft would be issued which brought everything together. I await this with interest so we can see how this combined proposal fits with MPTCP.

Regards,
Alan

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 5 Aug 2016 04:23:47 +0000

In-line sorry was on the road yesterday

From: Christoph Paasch <[email-masked]<mailto:[email-masked]>> on behalf of Christoph Paasch <[email-masked]<mailto:[email-masked]>>
Date: Thursday 4 August 2016 at 06:32
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: Tommy Pauly <[email-masked]<mailto:[email-masked]>>, MultiPath TCP - IETF WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

Hello,

On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

WH> we added it in the payload due to limited option space available in TCP

WH> Latency matters here and people already experienced that additional signaling messages with its roundtrip  degrades QoE. Even adding 2 message is not the right way to go and hence we want to add the informational elements in the messages in MPTCP. As such we need to enhance the information elements in TCP/MPTCP protocol to indicate that there is some data available that needs to be consumed by the proxy to operate properly. You need to extend the protocol to provide this capability in my view. The addition of adding a sub flow in MPTCP also provides addressing information and we need similar information for the MPTCP proxy (do the proxy or not, src/dst info, etc). We carry the data in the SYN due to limited option space but we could carry it in the option data as well. As such it becomes TCP specific and we believe it is best to leverage on the TCP framework to extend  this capability.

Cheers,
Christoph

---

From: <[email-masked]>
Date: Fri, 5 Aug 2016 05:44:13 +0000

Hi Alan,

Please see inline.

Cheers,
Med

Envoyé : jeudi 4 août 2016 14:33

Hi Med,

Inline...

Cc : Henderickx, Wim (Nokia - BE); [email-masked]<mailto:[email-masked]>

But this information doesn’t need to be read or understood by a MPTCP stack!
[Med] It needs to be read by the “MPTCP proxy” stack.

It is telling the proxy application, which sits above MPTCP,
[Med] This is implementation-specific. We are defining a new functional entity called “MPTCP Proxy”. The internal structure of such element is really implementation-specific.

where to forward the following payload data to.

This signal is a protocol which is not specific to MPTCP, and is in no way integrated with the rest of the MPTCP protocol.
[Med] I still don’t understand this argument as we are defining something “NEW”: Network-assisted MPTCP in addition to the existing end-to-end MPTCP.

The proxy application defers to the MPTCP stack (or interacts with it, for finer control) in order to set up new subflows.
[Med] I don’t parse what is meant by “defers” and “stack” here although I suspect those are implementation details that may or may not be followed by a given implementation.

[ Snip]

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 04 Aug 2016 23:00:43 -0700

Hello,

inline...

> On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:
> 
> From: Christoph Paasch <[email-masked] <mailto:[email-masked]>> on behalf of Christoph Paasch <[email-masked] <mailto:[email-masked]>>
> Cc: Tommy Pauly <[email-masked] <mailto:[email-masked]>>, MultiPath TCP - IETF WG <[email-masked] <mailto:[email-masked]>>
>> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <[email-masked] <mailto:[email-masked]>> wrote:
> WH> Latency matters here and people already experienced that additional signaling messages with its roundtrip  degrades QoE. Even adding 2 message is not the right way to go and hence we want to add the informational elements in the messages in MPTCP.

I am 100% sure that the way I described it is not adding more latency compared to the current plain-mode option proposal. Can you please explain, how my suggestion "degrades QoE" (compared to the plain-mode option) ?

> As such we need to enhance the information elements in TCP/MPTCP protocol to indicate that there is some data available that needs to be consumed by the proxy to operate properly. You need to extend the protocol to provide this capability in my view.
> The addition of adding a sub flow in MPTCP also provides addressing information and we need similar information for the MPTCP proxy (do the proxy or not, src/dst info, etc).
> We carry the data in the SYN due to limited option space but we could carry it in the option data as well. As such it becomes TCP specific and we believe it is best to leverage on the TCP framework to extend  this capability. 

Wrt. to "as such it becomes TCP specific" : Just because one arbitrarily puts some information in the TCP-option space does not make the information TCP-specific by design...

Let's put MPTCP aside for a moment.

Basically, the network that you are targeting has some characteristics that make a certain transport protocol more adapt for a certain leg of the end-to-end path. So, the goal is to enable the use of a special transport protocol over this leg of the network.
To do so, the byte-stream that is sent by the application from the client/server needs to be taken out of TCP and transmitted over this special transport protocol. Thus, the TCP-connection is being terminated at the CPE such that the byte-stream can be extracted out of TCP. This byte-stream is then sent over the specialized transport protocol to the concentrator on a specific port-number. The concentrator then terminates the special transport protocol so that it can extract the byte-stream out of it and sends the byte-stream to the final server over TCP.
Now, as the concentrator is not always on the IP-path between CPE and server, the CPE actually needs to use the destination IP-address of the concentrator in the segments that are using the specialized transport protocol. So, this is the "plain-mode" that you are addressing. To let the concentrator send the byte-stream to the final server, the CPE needs to tell to the concentrator which IP the server has. To do so, the CPE places this information in the payload of the first segment that it sends to the concentrator by using the specialized transport protocol. This is exactly what you are doing with the plain-mode option.

As you can see, in the above description of the hybrid access solution, there is nothing that is specific to MPTCP and nothing specific to the use of multiple interfaces or hybrid accesses. The sole use of the plain-mode option is to convey to the concentrator what the IP-address of the server is. Whether or not to do proxying is simply done by addressing the traffic to the concentrator by using a the proxy port-number.

So, standardizing this is probably useful. But should not be done as part of MPTCP, because the plain-mode option is orthogonal to MPTCP.

Cheers,
Christoph

---

From: <[email-masked]>
Date: Fri, 5 Aug 2016 06:58:05 +0000

Christoph,

The Leg you are talking about however is exactly an hybrid access leg, and that is exactly where MPTCP comes in. So this is not independent of hybrid access. I have said in a previous conversation, that there are other options for that leg, but that MPTCP has already a lot of nice features and properties for that leg and has only a very small set of problems (as Med nicly summarized). That problems we would like to be fixed for that particular deployment option of MPTCP. And yes we could open the whole discussion of something new or different for that leg.

Marcus

<snip>

Cheers,
Christoph

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 5 Aug 2016 13:32:33 +0000

In-line

Date: Friday 5 August 2016 at 08:00

Hello,

inline...

On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

WH10> my understanding is that you propose to add an additional out of band singling which need to negotiate the capabilities. This means extra signaling on top of what MPTCP does, so this is where your extra latency comes from.

Wrt. to "as such it becomes TCP specific" : Just because one arbitrarily puts some information in the TCP-option space does not make the information TCP-specific by design...
WH10> if 99% of what we need is in the MPTCP stack why should we not use this. We have multi-path, we get congestion management, re-ordering, etc in MPTCP and we need this for the hybrid access use case. Our goal is to extend the capabilities on top of MPTCP since it does not of what we need. We just need to enhance it with some capabilities specific to the hybrid access use case and if you don’t need them you can avoid them.

WH10> I get what you say but if I can re-use 99% of what is in MPTCP why should I define a new protocol to achieve the same thing. I can add something to the protocol to achieve the functionality, why should we not leverage this. This is why we call this an MPTCP proxy. If people don’t want to use it they don’t have to consume it. If people want to use the mechanism in another protocol they can. We just want to add this capability on top of an already existing MPTCP protocol which give us the capabilities we need. that’s all

Cheers,
Christoph

---

From: <[email-masked]>
Date: Fri, 5 Aug 2016 13:45:41 +0000

Re-,

Fully agree with Wim. It is all about a pragmatic solution to an engineering problem.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Henderickx, Wim (Nokia - BE)
Envoyé : vendredi 5 août 2016 15:33
À : Christoph Paasch
Cc : MultiPath TCP - IETF WG
Objet : Re: [multipathtcp] towards a potential work item on two-ended proxy

In-line

Hello,

inline...

Hello,

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

Cheers,
Christoph

---

From: <[email-masked]>
Date: Fri, 5 Aug 2016 15:07:34 +0000

+1

Von: multipathtcp <[email-masked]> im Auftrag von "[email-masked]" <[email-masked]>
Datum: Freitag, 5. August 2016 um 15:45
An: "Henderickx, Wim (Nokia - BE)" <[email-masked]>, Christoph Paasch <[email-masked]>
Cc: MultiPath TCP - IETF WG <[email-masked]>
Betreff: Re: [multipathtcp] towards a potential work item on two-ended proxy

Re-,

Cheers,
Med

In-line

Hello,

inline...

Hello,

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

Cheers,
Christoph

---

From: David Allan I <[email-masked]>
Date: Fri, 5 Aug 2016 17:11:08 +0000

Been hard enough just to read this whole thread, let alone work up the gumption to comment  ☺ , but here goes…

I’m not sure I would characterize this as “pragmatic”. It seems to be that IF you wish to define a “proxy path-bonding avec flow control” mechanism where that “special transport protocol” happens to be MP-TCP, it would be desirable if the solution was self contained. Inventing “additional stuff” outside of MP-TCP to enable this seems to me as gratuitous overkill….and simply inviting a proliferation of solutions….

My 2 cents
Dave

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 05, 2016 8:08 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy

+1

Von: multipathtcp <[email-masked]<mailto:[email-masked]>> im Auftrag von "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Datum: Freitag, 5. August 2016 um 15:45
An: "Henderickx, Wim (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>, Christoph Paasch <[email-masked]<mailto:[email-masked]>>
Cc: MultiPath TCP - IETF WG <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [multipathtcp] towards a potential work item on two-ended proxy

Re-,

Cheers,
Med

In-line

Hello,

inline...

Hello,

Alan, in-line

Hi Wim, all,

Comment inline...

Transparent Mode

Plain Mode

Cheers,
Christoph

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 05 Aug 2016 19:12:25 -0700

Inline

> On Aug 5, 2016, at 6:32 AM, Henderickx, Wim (Nokia - BE) <[email-masked]> wrote:
>> On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <[email-masked] <mailto:[email-masked]>> wrote:

No, there is no extra signaling compared to the plain-mode option, as what I am proposing would be to put the SOCKS v4 framing in the SYN. So, there is no additional round-trip here.
Please explain (with a flow-diagram of segments sent) how the latency is higher in this proposal.

> WH10> I get what you say but if I can re-use 99% of what is in MPTCP why should I define a new protocol to achieve the same thing. I can add something to the protocol to achieve the functionality,…

What we are basically saying is that you could think beyond MPTCP and not lock yourself into it. The benefit of the plain-mode option goes far beyond your current use-case (which is MPTCP-centric). So, designing it in a way that it is independent from the transport-protocol would add far more value to it.
The good thing is that designing it in such a way that it is independent from the transport-protocol is very straight-forward. You basically take the plain-mode option in its current form and remove the subtype-field. Then you are done. Easy :)

Cheers,
Christoph

---

From: Alan Ford <[email-masked]>
Date: Sat, 6 Aug 2016 21:47:45 +0100

Absolutely, and I'm excited to see MPTCP finding a use in this way :-)

My concerns are around pragmatism too: firstly, ensuring any solution does
not add complexity or introduce issues in the base MPTCP protocol where it
is not required, or for what is a specialist use; and secondly, that you
are not limiting functionality of your solution in the future.

However, I do not think there is much point continuing this debate until we
see the consolidated proxy draft (plain mode + transparent) which was
discussed in Berlin - this may well make the goals of this work clearer.

Regards,
Alan

On Friday, 5 August 2016, <[email-masked]> wrote:

> *De :* multipathtcp [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *De la
> part de* Henderickx, Wim (Nokia - BE)
> *Envoyé :* vendredi 5 août 2016 15:33
> *À :* Christoph Paasch
> *Cc :* MultiPath TCP - IETF WG
> *Objet :* Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> In-line
>
>
>
> *From: *Christoph Paasch <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of
> Christoph Paasch <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Date: *Friday 5 August 2016 at 08:00
> *To: *Wim Henderickx <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc: *Tommy Pauly <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, MultiPath TCP - IETF
> WG <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hello,
>
>
>
> inline...
>
>
>
> On Aug 4, 2016, at 9:23 PM, Henderickx, Wim (Nokia - BE) <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> *From: *Christoph Paasch <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of
> Christoph Paasch <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Date: *Thursday 4 August 2016 at 06:32
> *To: *Wim Henderickx <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc: *Tommy Pauly <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, MultiPath TCP - IETF
> WG <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hello,
>
>
>
> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> *From: *<[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of Tommy
> Pauly <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> *Date: *Thursday 4 August 2016 at 02:10
> *To: *Wim Henderickx <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc: *Alan Ford <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
>
>
> On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> Alan, in-line
>
>
>
> *From: *Alan Ford <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Date: *Wednesday 3 August 2016 at 09:20
> *To: *Wim Henderickx <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc: *Rao Shoaib <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject: *Re: [multipathtcp] towards a potential work item on two-ended
> proxy
>
>
>
> Hi Wim, all,
>
>
>
> Comment inline...
>
>
>
> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On 02/08/16 15:52, "Alan Ford" <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
> WH> the main difference is mainly DST IP is changed to get explicit
> routing to the proxy versus being implicit in the transparent case
>
>
>
> context about what kind of proxy is being intercepted. You could be sending
> in good faith expecting it to be picked up by Proxy from Operator A, but in
> fact is picked up by Operator B.
>
> WH> the network assisted proxy is mainly targeting single
> operator/controlled operator use cases to avoid these issues.
>
>
> simple a signal that says “everything that follows is actually targeted for
> IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could
> know where to find a proxy (e.g. a well-known anycast address) then
> Which is the point of the signalling protocol - the proposed “plain mode
> option” which is actually carried in the payload. My issue with this is
> that this is _not MPTCP-specific_. This is simply a signal above the
> transport layer to inform a proxy what the real destination is.
>
>
>
> WH> I hear, you and I understand but we have an explicit use case for this
> with MPTCP and so far not in any other protocol. Hence I think it is good
> to extend MPTCP with this capability and liase with other WG(s) about this.
>
>
>
> While you may have a use-case for having proxies work with your MPTCP
> solution, it does not directly follow that the MPTCP protocol or WG is the
> best place to specify how the proxy works. This really does seem like a
> proxy solution that can be made more generic, and at the very least belongs
> as a protocol that is run within the MPTCP stream. This is what the SOCKS
> protocol does, and there is no reason you can't run SOCKS over MPTCP, or
> create a new variant of SOCKS or a similar protocol that you will run on
> top of MPTCP for your solution. Indeed, it could be seen as a benefit to
> work on the proxying solution independently from MPTCP, since that way it
> can be used for other transports. The end result will be the same, and the
> architecture will be cleaner.
>
>
>
> WH> given the extension is specific in TCP?MPTCP since we carry the
> information in a SYN packet it becomes specific to the protocol and hence I
> still believe it fits.
>
>
>
> The information is actually carried in the payload. So, it is not really
> part of TCP/MPTCP. Carrying it in the SYN is just because TCP does not
> prevent carrying data in the SYN-segment.
>
>
>
> Other transport mechanisms have other means and can adopt a similar
> information element but the way the protocol consumes it is specific and
> should be done in the protocol afais.
>
>
>
> I disagree that the information is consumed by MPTCP. It is rather
> consumed by the application sitting right on top of MPTCP, because this is
> the one that is reading the data out of the MPTCP-stream and forwarding it
> over to final destination. And MPTCP itself is not really using the
> plain-mode option.
>
>
>
> If you look at Socks v4, it is actually carrying the exact same
> information than the plain-mode option (besides the protocol-field). So, an
> implementation could easily put the Socks-client request in the
> SYN-payload. The proxy who receives that can then (after connecting to the
> final server) reply in the SYN/ACK with the Socks-server option in the
> SYN/ACK's payload. And from there on, the data will be forwarded from one
> side to the other.
>
>
>
> WH> Latency matters here and people already experienced that additional
> signaling messages with its roundtrip  degrades QoE. Even adding 2 message
> is not the right way to go and hence we want to add the informational
> elements in the messages in MPTCP.
>
>
>
> I am 100% sure that the way I described it is not adding more latency
> compared to the current plain-mode option proposal. Can you please explain,
> how my suggestion "degrades QoE" (compared to the plain-mode option) ?
>
>
>
> WH10> my understanding is that you propose to add an additional out of
> band singling which need to negotiate the capabilities. This means extra
> signaling on top of what MPTCP does, so this is where your extra latency
> comes from.
>
>
>
> As such we need to enhance the information elements in TCP/MPTCP protocol
> to indicate that there is some data available that needs to be consumed by
> the proxy to operate properly. You need to extend the protocol to provide
> this capability in my view.
>
> The addition of adding a sub flow in MPTCP also provides addressing
> information and we need similar information for the MPTCP proxy (do the
> proxy or not, src/dst info, etc).
>
> We carry the data in the SYN due to limited option space but we could
> carry it in the option data as well. As such it becomes TCP specific and we
> believe it is best to leverage on the TCP framework to extend  this
> capability.
>
>
>
> Wrt. to *"as such it becomes TCP specific" *: Just because one
> arbitrarily puts some information in the TCP-option space does not make the
> information TCP-specific by design...
>
> WH10> if 99% of what we need is in the MPTCP stack why should we not use
> this. We have multi-path, we get congestion management, re-ordering, etc in
> MPTCP and we need this for the hybrid access use case. Our goal is to
> extend the capabilities on top of MPTCP since it does not of what we need.
> We just need to enhance it with some capabilities specific to the hybrid
> access use case and if you don’t need them you can avoid them.
>
>
>
>
>
>
>
> Basically, the network that you are targeting has some characteristics
> that make a certain transport protocol more adapt for a certain leg of the
> end-to-end path. So, the goal is to enable the use of a special transport
> protocol over this leg of the network.
>
> To do so, the byte-stream that is sent by the application from the
> client/server needs to be taken out of TCP and transmitted over this
> special transport protocol. Thus, the TCP-connection is being terminated at
> the CPE such that the byte-stream can be extracted out of TCP. This
> byte-stream is then sent over the specialized transport protocol to the
> concentrator on a specific port-number. The concentrator then terminates
> the special transport protocol so that it can extract the byte-stream out
> of it and sends the byte-stream to the final server over TCP.
>
> Now, as the concentrator is not always on the IP-path between CPE and
> server, the CPE actually needs to use the destination IP-address of the
> concentrator in the segments that are using the specialized transport
> protocol. So, this is the "plain-mode" that you are addressing. To let the
> concentrator send the byte-stream to the final server, the CPE needs to
> tell to the concentrator which IP the server has. To do so, the CPE places
> this information in the payload of the first segment that it sends to the
> concentrator by using the specialized transport protocol. This is exactly
> what you are doing with the plain-mode option.
>
>
>
>
>
> As you can see, in the above description of the hybrid access solution,
> there is nothing that is specific to MPTCP and nothing specific to the use
> of multiple interfaces or hybrid accesses. The sole use of the plain-mode
> option is to convey to the concentrator what the IP-address of the server
> is. Whether or not to do proxying is simply done by addressing the traffic
> to the concentrator by using a the proxy port-number.
>
>
>
> So, standardizing this is probably useful. But should not be done as part
> of MPTCP, because the plain-mode option is orthogonal to MPTCP.
>
>
>
> WH10> I get what you say but if I can re-use 99% of what is in MPTCP why
> should I define a new protocol to achieve the same thing. I can add
> something to the protocol to achieve the functionality, why should we not
> leverage this. This is why we call this an MPTCP proxy. If people don’t
> want to use it they don’t have to consume it. If people want to use the
> mechanism in another protocol they can. We just want to add this capability
> on top of an already existing MPTCP protocol which give us the capabilities
> we need. that’s all
>
>
>
>
>
> Cheers,
>
> Christoph
>
>
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Sun, 7 Aug 2016 09:43:00 +0000

Date: Saturday 6 August 2016 at 04:12

Inline

On Aug 5, 2016, at 6:32 AM, Henderickx, Wim (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

Transparent Mode

Plain Mode

WH11> ok I see now, so what you are saying is along the same mechanism in the plain draft, but use a generic framing which can be reused. As such the latency is similar here. More on this later.

WH11> I see what you are saying, now there are some specifics here on why we went to MPTCP option so far. Since we transport the information in the SYN we are bound with kind/length semantics since we embed them in SYN and we need to ensure we can distinguish the (proxy) information from the real data. Also also need DST IP, SRC IP (not in socks afaik), protocol (not generic in SOCKS). If there are better proposal lets flush them out, but there are some constraints as I mentioned.

Cheers,
Christoph

---

From: <[email-masked]>
Date: Mon, 8 Aug 2016 09:19:45 +0000

Afraid not. 
(personal view) if I get it right, a (?router, ?proxy) has to distinguish whether the (?mptcp signalling message ?every packet) is part of end-to-end mptcp connection, or part of mptcp proxied connection. That seems to add overhead, an may mean you have to be careful about the deployment.

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Mon, 8 Aug 2016 16:49:01 +0000

Phil, in-line

> 
>A dual ended proxy so far was meant in a controlled environment, so indeed if you have this requirement you need to control deployment.