Subject: [multipathtcp] Re-chartering MPTCP Issue #2: Proxies

From: <[email-masked]>
Date: Tue, 3 Apr 2012 14:58:03 +0100

#2 of a series of emails to try and reach consensus about the re-charter.
This email is about whether we do any Proxy work. We didn't reach consensus during the WG meeting. We need to see if we can reach consensus on the mailing list.

I think I heard 4 different points of view

1.       We shouldn't do any specification work on proxies

2.       We should do Experimental track work on 'proxies'

3.       (&/or) We should do Experimental track work on 'anchors'

4.       (&/or) We should do Experimental track work on 'transparent performance enhancing proxy'

The first point of view is that we shouldn't specify proxies. Any such work should be left for experiments, but not protocol specification on the standards track.
Perhaps relevant is that there is IPR in this area, see Randall Stewart's comments during this meeting and also IETF-81 meeting. If i get it right, there is IPR from at least MIT & Cisco.

The second point of view would allow work on the proxy part of draft-hampel-mptcp-proxies-anchors<http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (& any similar ideas). The MPTCP proxy allows one end host to run ordinary TCP (the other end is MPTCP), with the proxy talking TCP to one end and MPTCP to the other. This assists incremental deployment.

The third point of view would allow work on the anchor part of draft-hampel-mptcp-proxies-anchors<http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (& any similar ideas). Both end hosts run MPTCP. The MPTCP anchor allows continuing connectivity after two mobile hosts move simultaneously, or one end host moves and the other is behind a firewall.

The fourth point of view would allow work on http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (& any similar ideas). Neither end host runs MPTCP. The proxy creates multiple paths between the proxy and the other (TCP) host. This may allow some of the benefits of MPTCP to be achieved whilst both ends are unaltered TCP hosts.

Please let us know your views on which of these 4 options we should go with, or if you want to suggest another option.

Thanks

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 3 Apr 2012 14:01:15 -0500

All,

I conducted an IPR search on multipath proxy and found the following patent applications:

(1) US patent application 2008/0144504 (Sun Microsystems) covers end-host-based multipath operation.
http://www.google.com/patents?id=3xSrAAAAEBAJ&printsec=abstract&zoom=4#v=onepage&q&f=false

(2) US patent application 2008/0062879 (Asankya Networks) covers the multipath proxy.
http://www.google.com/patents?id=U8uoAAAAEBAJ&printsec=abstract&zoom=4#v=onepage&q&f=false

In other words: If we are concerned about IPR we should drop MPTCP altogether.

Regards,
Georg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 03, 2012 9:58 AM
To: [email-masked]
Subject: [multipathtcp] Re-chartering MPTCP Issue #2: Proxies

Thanks

---

From: Mark Handley <[email-masked]>
Date: Tue, 3 Apr 2012 20:15:21 +0100

> In other words: If we are concerned about IPR we should drop MPTCP

"In other words: If we are concerned about IPR we should drop Internet
standards altogether."

There - fixed that for you.  I've been involved in enough patent cases
recently to be pretty sure you can't do anything in the whole area of
network protocols without someone thinking you've infringed their
patent.  At least in the case of MPTCP, there's a ton of prior art on
the basic concept.

 - Mark

---

From: Tacettin Ayar <[email-masked]>
Date: Wed, 04 Apr 2012 02:27:02 +0200

Dear Philip,

We believe that the formulation for the fourth point of view should be  
re-worded as:

The fourth point of view would allow work on  
http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (& any  
similar ideas). Neither end host runs MPTCP. The proxy creates  
multiple paths between the proxy and the other (TCP) host or another  
proxy. This will allow benefits of using multiple paths whilst both  
ends are unaltered TCP hosts.

Best,

Tacettin

Quoting [email-masked]:

> This email is about whether we do any Proxy work. We didn't reach  
> consensus during the WG meeting. We need to see if we can reach  
> consensus on the mailing list.
>
> The first point of view is that we shouldn't specify proxies. Any  
> such work should be left for experiments, but not protocol  
> specification on the standards track.
> Perhaps relevant is that there is IPR in this area, see Randall  
> Stewart's comments during this meeting and also IETF-81 meeting. If  
> i get it right, there is IPR from at least MIT & Cisco.
>
> The second point of view would allow work on the proxy part of  
> draft-hampel-mptcp-proxies-anchors<http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (& any similar ideas). The MPTCP proxy allows one end host to run ordinary TCP (the other end is MPTCP), with the proxy talking TCP to one end and MPTCP to the other. This assists incremental  
> deployment.
>
> The third point of view would allow work on the anchor part of  
> draft-hampel-mptcp-proxies-anchors<http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (& any similar ideas). Both end hosts run MPTCP. The MPTCP anchor allows continuing connectivity after two mobile hosts move simultaneously, or one end host moves and the other is behind a  
> firewall.
>
> The fourth point of view would allow work on  
> http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (& any  
> similar ideas). Neither end host runs MPTCP. The proxy creates  
> multiple paths between the proxy and the other (TCP) host. This may  
> allow some of the benefits of MPTCP to be achieved whilst both ends  
> are unaltered TCP hosts.
>
> Please let us know your views on which of these 4 options we should  
> go with, or if you want to suggest another option.
>
> Thanks
>

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 4 Apr 2012 10:10:33 +0300

Hi,

I am for options 2&3, but then we need to be really careful about IPR as other people pointed out.

Option 4 proposes a completely different beast: in-network, load-adaptive traffic engineering on a per flow granularity. This is a very difficult problem to solve (some call it the holy grail of routing) - I don't want this in the charter.

Cheers,
Costin

On 4 Apr 2012, at 03:27, Tacettin Ayar wrote:

> Dear Philip,
> 
> We believe that the formulation for the fourth point of view should be re-worded as:
> 
> The fourth point of view would allow work on http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (& any similar ideas). Neither end host runs MPTCP. The proxy creates multiple paths between the proxy and the other (TCP) host or another proxy. This will allow benefits of using multiple paths whilst both ends are unaltered TCP hosts.
> 
> Best,
> 
> Tacettin
> 
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Daniel Migault <[email-masked]>
Date: Wed, 4 Apr 2012 09:55:20 +0200

I am for 2&3, but I don't strongly oppose 4.

On Wed, Apr 4, 2012 at 9:10 AM, Costin Raiciu <[email-masked]> wrote:

> Option 4 proposes a completely different beast: in-network, load-adaptive
> traffic engineering on a per flow granularity. This is a very difficult
> problem to solve (some call it the holy grail of routing) - I don't want
> this in the charter.
>
> Cheers,
> Costin
>
> similar ideas). Neither end host runs MPTCP. The proxy creates multiple
> paths between the proxy and the other (TCP) host or another proxy. This
> will allow benefits of using multiple paths whilst both ends are unaltered
> TCP hosts.
> >
> > Best,
> >
> > Tacettin
> >
> >
> >
> consensus during the WG meeting. We need to see if we can reach consensus
> on the mailing list.
> >>
> >> The first point of view is that we shouldn't specify proxies. Any such
> work should be left for experiments, but not protocol specification on the
> standards track.
> Stewart's comments during this meeting and also IETF-81 meeting. If i get
> it right, there is IPR from at least MIT & Cisco.
> >>
> draft-hampel-mptcp-proxies-anchors<
> http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (&
> any similar ideas). The MPTCP proxy allows one end host to run ordinary TCP
> (the other end is MPTCP), with the proxy talking TCP to one end and MPTCP
> to the other. This assists incremental deployment.
> >>
> draft-hampel-mptcp-proxies-anchors<
> http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> (&
> any similar ideas). Both end hosts run MPTCP. The MPTCP anchor allows
> continuing connectivity after two mobile hosts move simultaneously, or one
> end host moves and the other is behind a firewall.
> >>
> similar ideas). Neither end host runs MPTCP. The proxy creates multiple
> paths between the proxy and the other (TCP) host. This may allow some of
> the benefits of MPTCP to be achieved whilst both ends are unaltered TCP
> hosts.
> >>
> >> Please let us know your views on which of these 4 options we should go
> with, or if you want to suggest another option.
> >>
> >> Thanks
> >>
> >
> >

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 4 Apr 2012 08:43:36 +0000

> 4.       (&/or) We should do Experimental track work on 'transparent performance enhancing proxy'

support for 1

don't see a need for a standard for interoperability reasons here

Lars

---

From: Łukasz Budzisz <[email-masked]>
Date: Wed, 04 Apr 2012 10:46:22 +0200

The formulation for the fourth point of view should be re-worded as:

/The fourth point of view would allow work on 
http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (& any 
similar ideas). Neither end host runs MPTCP. The proxy creates multiple 
paths between the proxy and the other (TCP) host or another proxy. This 
will allow benefits of using multiple paths  whilst both ends are 
unaltered TCP hosts. /

Best regards,
Lukasz

On 03/04/12 15:58, [email-masked] wrote:
> This email is about whether we do any Proxy work. We didn’t reach 
> 1.We shouldn’t do any specification work on proxies
>
> 2.We should do Experimental track work on ‘proxies’
>
> 3.(&/or) We should do Experimental track work on ‘anchors’
>
> 4.(&/or) We should do Experimental track work on ‘transparent 
> performance enhancing proxy’
>
> The first point of view is that we shouldn’t specify proxies. Any such 
> work should be left for experiments, but not protocol specification on 
> the standards track.
>
> Stewart’s comments during this meeting and also IETF-81 meeting. If i 
> get it right, there is IPR from at least MIT & Cisco.
>
> draft-hampel-mptcp-proxies-anchors 
> <http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> 
> (& any similar ideas). The MPTCP proxy allows one end host to run 
> ordinary TCP (the other end is MPTCP), with the proxy talking TCP to 
> one end and MPTCP to the other. This assists incremental deployment.
>
> draft-hampel-mptcp-proxies-anchors 
> <http://tools.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt> 
> (& any similar ideas). Both end hosts run MPTCP. The MPTCP anchor 
> allows continuing connectivity after two mobile hosts move 
> simultaneously, or one end host moves and the other is behind a firewall.
>

---

From: Tacettin Ayar <[email-masked]>
Date: Wed, 04 Apr 2012 11:36:42 +0200

Hi,

Quoting Costin Raiciu <[email-masked]>:

> Option 4 proposes a completely different beast: in-network,  
> load-adaptive traffic engineering on a per flow granularity. This is  
> a very difficult problem to solve (some call it the holy grail of  
> routing) - I don't want this in the charter.
I don't think so. It doesn't propose something 'completely' different.  
It carries what MPTCP does on end-hosts into the network: If there are  
multiple paths between proxies, use them for TCP benefits!

Best,

Tacettin

>> multiple paths between the proxy and the other (TCP) host or  
>> another proxy. This will allow benefits of using multiple paths  
>> whilst both ends are unaltered TCP hosts.
>>
>> Best,
>>
>> Tacettin
>>
>>
>>
>>> 4.       (&/or) We should do Experimental track work on  
>>> 'transparent performance enhancing proxy'
>>>
>>> Stewart's comments during this meeting and also IETF-81 meeting.  
>>> If i get it right, there is IPR from at least MIT & Cisco.
>>>
>>> multiple paths between the proxy and the other (TCP) host. This  
>>> may allow some of the benefits of MPTCP to be achieved whilst both  
>>> Please let us know your views on which of these 4 options we  
>>> should go with, or if you want to suggest another option.
>>>
>>> Thanks
>>>
>>
>>

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 04 Apr 2012 11:42:07 +0200

Hello,
> I am for options 2&3, but then we need to be really careful about IPR as other people pointed out.

Same for me. Working on 2 & 3 should encourage patent owners to clarify
their claims and if IPR issues are too strong we can decide later to
stop working on a standardised solution.

I don't think that we should work on solutions where MPTCP is not used
on the endhosts. There is a lot of prior work on performance enhancing
proxies that could use multiple paths without requiring MPTCP.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 4 Apr 2012 12:51:42 +0300

Let me explain why I think this is a different beast.

Case 1. Deploy two MPTCP proxies (or other similar solutions) splitting individual TCP connections on the two paths. Nothing to standardize for MPTCP itself here, maybe proxy discovery - but this is out of scope of the MPTCP WG as far as I am concerned.

Case 2. Try to achieve a more lightweight solution; assume we want no buffering in the proxies - packets must be passed immediately on the paths available, and retransmissions are end-to-end.  Further assume that something like the coupled congestion controller is used by the proxy to decide how many packets to put on each path.

The first problem is that reordering due to the different paths will kill TCP throughput - but let's assume that we can fix this somehow (scheduling packets requires buffers, and does not always work so it's not a great solution). 
The second bigger problem is that upon a loss on any path the TCP will halve its rate - this will reduce the throughput enough that the available paths are not fully utilized (it is very easy to construct cases where this happens). Hence, the whole reason for deploying the proxies have dissapeared.

Ok, so what shall we do? Coupled congestion control doesn't work - we should resort to load-aware traffic engineering which has been heaviliy researched but no truly satisafactory solution was found. This is the holy grail I was talking about.

To summarize my opinion: 
Case 1 - no need to standardize anything in the MPTCP WG
Case 2 - lots of research needed, far from standards-ready 

But I may be missing something.
Costin

On 4 Apr 2012, at 12:36, Tacettin Ayar wrote:

> I don't think so. It doesn't propose something 'completely' different. It carries what MPTCP does on end-hosts into the network: If there are multiple paths between proxies, use them for TCP benefits!
> 
> 
> Best,
> 
> Tacettin
> 
>> 
>> Cheers,
>> Costin
>>

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 4 Apr 2012 08:36:44 -0500

For #2, I am in support of 2&3, i.e. proxy and anchors.

I think we should keep the door open for further discussions and eventually future work on proposals along the lines of 4. Currently, it seems that many people do not really understand the scope of this work.

Georg

Thanks

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Apr 2012 14:03:58 -0400

> 1.       We shouldn't do any specification work on proxies

   Work on standardizing proxies seems more than six months premature.
(Research on implementing and testing would be welcome, but it doesn't feel
like standards-track work.)

--
John Leslie <[email-masked]>

---

From: Lukasz Budzisz <[email-masked]>
Date: Thu, 05 Apr 2012 00:36:56 +0200

On 04/04/12 20:03, John Leslie wrote:
> [email-masked]<[email-masked]>  wrote:

Why?

Isn't it the problem that already arises in the wireless scenarios?

BR,
Lukasz

---

From: Tacettin Ayar <[email-masked]>
Date: Thu, 05 Apr 2012 01:00:16 +0200

Hi,

Quoting Costin Raiciu <[email-masked]>:

> Case 1. Deploy two MPTCP proxies (or other similar solutions)  
> splitting individual TCP connections on the two paths. Nothing to  
> standardize for MPTCP itself here, maybe proxy discovery - but this  
> is out of scope of the MPTCP WG as far as I am concerned.
>

DEFINITELY proxy discovery should be included in the standardization.  
MPTCP mechanisms or some other multipath transport protocol may be  
used between proxies. Thus, this protocol must be negotiated  
during/after proxy discovery, which needs to be standardized as well.  
Assume that proxies decided on using MPTCP. Then, proxies must  
advertise their available interface IP addresses to the peer... etc.

> Case 2. Try to achieve a more lightweight solution; assume we want  
> no buffering in the proxies - packets must be passed immediately on  
> the paths available, and retransmissions are end-to-end.  Further  
> assume that something like the coupled congestion controller is used  
> by the proxy to decide how many packets to put on each path.
>
> The first problem is that reordering due to the different paths will  
> kill TCP throughput - but let's assume that we can fix this somehow  
> (scheduling packets requires buffers, and does not always work so  
> it's not a great solution).

I don't agree with that. Yes, buffering is required. But, must it be  
on the proxies? I don't think so! When TCP sender and receiver have  
enough buffers, then out-of-order packets don't have to kill TCP  
throughput! Although TCP receiver will send DUPACKs in case of  
out-of-order packet arrivals, proxy may shield them from TCP sender.  
TCP sender will not reduce its sending rate unnecessarily. For an  
initial attempt for this, see our technical report, Chapter 5: A  
Standalone SCAP.

You may find the technical report at:  
http://www.tkn.tu-berlin.de/menue/publications/tkn_technical_report_series/

> The second bigger problem is that upon a loss on any path the TCP  
> will halve its rate - this will reduce the throughput enough that  
> the available paths are not fully utilized (it is very easy to  
> construct cases where this happens). Hence, the whole reason for  
> deploying the proxies have dissapeared.

It is a well known TCP problem (See our technical report, Section 2.5:  
Isolate Losses on One Path From The Other Paths). Yes, it is hard to  
do something without directly playing with the TCP cwnd/sstresh  
values. But, if TCP sender estimates number of in-flight packets and  
adjusts its sending rate accordingly, then proxies are still  
beneficial (although may not be optimal). To ease TCP sender's  
estimation, DUPACKs must be passed to TCP sender when there are packet  
losses.

>
> Ok, so what shall we do? Coupled congestion control doesn't work -  
> we should resort to load-aware traffic engineering which has been  
> heaviliy researched but no truly satisafactory solution was found.  
> This is the holy grail I was talking about.
>
> To summarize my opinion:
>>> load-adaptive traffic engineering on a per flow granularity. This  
>>> is a very difficult problem to solve (some call it the holy grail  
>>> of routing) - I don't want this in the charter.
>> I don't think so. It doesn't propose something 'completely'  
>> different. It carries what MPTCP does on end-hosts into the  
>> network: If there are multiple paths between proxies, use them for  
>> TCP benefits!
>>
>>
>> Best,
>>
>> Tacettin
>>
>>>
>>> Cheers,
>>> Costin
>>>
>>>> http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (&  
>>>> any similar ideas). Neither end host runs MPTCP. The proxy  
>>>> creates multiple paths between the proxy and the other (TCP) host  
>>>> or another proxy. This will allow benefits of using multiple  
>>>> paths whilst both ends are unaltered TCP hosts.
>>>>
>>>> Best,
>>>>
>>>> Tacettin
>>>>
>>>>
>>>>
>>>>> This email is about whether we do any Proxy work. We didn't  
>>>>> reach consensus during the WG meeting. We need to see if we can  
>>>>> reach consensus on the mailing list.
>>>>>
>>>>> The first point of view is that we shouldn't specify proxies.  
>>>>> Any such work should be left for experiments, but not protocol  
>>>>> http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy (&  
>>>>> any similar ideas). Neither end host runs MPTCP. The proxy  
>>>>> creates multiple paths between the proxy and the other (TCP)  
>>>>> host. This may allow some of the benefits of MPTCP to be  
>>>>> achieved whilst both ends are unaltered TCP hosts.
>>>>>

---

From: Tacettin Ayar <[email-masked]>
Date: Thu, 05 Apr 2012 03:16:10 +0200

Hi,

> proxies that could use multiple paths without requiring MPTCP.

Do I get it correctly? We shouldn't work on MPTCP proxies since THERE  
ARE SOME MULTI PATH TCP PROXY PROPOSALS.

Were there no end-host based multipath TCP proposals before MPTCP  
(e.g., pTCP, Horizon, Multipath TCP, ...)???? Was it the reason that  
MPTCP work HAS NOT BEEN STARTED????

Best,

Tacettin

---

From: <[email-masked]>
Date: Thu, 5 Apr 2012 11:40:40 +0100

'specification' was probably the wrong word for me to use.

The suggestion of options 2, 3 and 4 about proxies is that we do work on the Experimental track. Standards track work for proxies is not on the table as an option in my opinion.

John - Can you clarify, do you think it's premature for any experimental-track proxy work? 

Thanks
phil

---

From: <[email-masked]>
Date: Thu, 5 Apr 2012 11:54:03 +0100

(personal reply)
In-line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tacettin Ayar
Sent: 05 April 2012 00:00
To: Costin Raiciu
Cc: [email-masked]
Subject: Re: [multipathtcp] Re-chartering MPTCP Issue #2: Proxies

Hi,

[phil] some of the scenarios presented had implicit proxy discovery, some had explicit - are the latter scenarios critical?

---

From: <[email-masked]>
Date: Thu, 5 Apr 2012 12:12:13 +0100

I think Olivier was saying that he thinks we should work on MPTCP proxy solutions where at least one end host is MPTCP-enabled, and that using (a pair of) Performance enhancing proxies doesn't need MPTCP.

On your other point, we had a lot of discussion during the BoF and other pre-WG discussions about why previous attempts at multipath TCP had not got deployed. We wanted to try and learn from these lessons in order to maximise the chances of MPTCP getting deployed. Several issues were raised, including being "friendly" to TCP on the wire, looking like TCP to apps (same API) and devising signalling that has the best chance possible of getting through middleboxes but falls back to TCP if there's a problem. A key point of Rfc6182 is to try and capture those lessons and detail the impact on high-level design decisions.
I don't remember us discussing the lack of proxies as a reason for the previous attempts at multipath TCP not getting deployed. I think this was because we implicitly wanted successful deployment to mean replacing TCP, ie on end hosts. 

Best wishes
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tacettin Ayar
Sent: 05 April 2012 02:16
To: [email-masked]
Subject: Re: [multipathtcp] Re-chartering MPTCP Issue #2: Proxies

Hi,

Best,

Tacettin

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Apr 2012 11:28:12 -0400

In terms of proxies, the MPTCP architecture (RFC 6182) does not
discuss these.  Middleboxes are considered something to be
traversed, and not as a vector for deploying MPTCP on top of.

Proxy work needs to be very strongly motivated if it is to be
pursued, and the specific proxy approach would need to also
be strongly motivated against alternatives.  There are a range
of possible proposals from "not too scary" to "horrifying", and
I don't think having an open door for proxy work is a good idea.

At this point in time, I would think the most that should be
looked at is what real problems there are that a proxy is needed
to solve and what proxy approach would be justified and how that
impacts the previously written architecture.  Doing specifications
is premature in my opinion.

Personally, I'm not very interested in proxies and would not
be likely to contribute cycles to working on them.

-- 
Wes Eddy
MTI Systems

---

From: John Leslie <[email-masked]>
Date: Thu, 5 Apr 2012 12:31:44 -0400

I noticed that Wes Eddy has already responded better that I can, but
Phil deserves a specific answer...

> experimental-track proxy work? 

   I have no objection to experimental-track work on MPTCP proxies, but
I am far from convinced it belongs in this WG at this time.

   I think there is a potential great benefit from existing proxies
using MPTCP as end-hosts themselves -- that deserves from this WG _only_
progressing MPTCP to Proposed Standard reasonably quickly: there are
no other issues we need to discuss for this use-case.

   If there is a benefit to such existing proxies locating other-end
proxies in order to do two-way MPTCP with hosts that don't yet do
MPTCP themselves, I don't believe that belongs in this WG.

   Nonetheless, I _will_ be interested in hearing the results of
experimental work in proxies using MPTCP.

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 5 Apr 2012 12:01:09 -0500

Hi John,

".. I think there is a potential great benefit from existing proxies
using MPTCP as end-hosts themselves -- that deserves from this WG _only_
progressing MPTCP to Proposed Standard reasonably quickly: there are
no other issues we need to discuss for this use-case."

This is what we understand under the term Proxy. Unfortunately, it _does_ require additional signaling even if the proxy remains transparent during connection establishment. 

Georg

---

From: John Leslie <[email-masked]>
Date: Sat, 7 Apr 2012 09:50:52 -0400

Hampel, K Georg (K Georg) <[email-masked]> wrote:
> [John Leslie wrote:]
> This is what we understand under the term Proxy. Unfortunately, it
> _does_ require additional signaling even if the proxy remains
> transparent during connection establishment. 

   I was thinking of proxies that don't attempt to be transparent.

   Having maintained such proxies for years, I'm possibly over-sensitive
to the security issues of proxies; but if we want to do signaling between
proxies, we _will_ have to get into security issues.

   I frankly don't believe it's worth the trouble: non-transparent proxies
have no such signaling needs, while transparent proxies strike me as a
mine-field of security issues.

   There may, of course, be experimental results showing that a transparent
proxy in one MPTCP path results in undetected data corruption. :^( I am
pessimistic about trying to solve that by MPTCP signaling between proxies.

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 9 Apr 2012 09:43:31 -0500

John, all,

I have the feeling there is a misunderstanding on what the MPTCP proxy should cover. 

Here's the simplest MPTCP proxy to be considered:

1) Creates MPTCP/TCP split connection between MPTCP-host and non-MPTCP host.

2) Resides on initial path; transparently inserts itself into connection.

3) Host authentication implicit with host's access authentication.

4) Proxy sends its IP address to MPTCP-host for generation of new subflows.

NOTE: This simple solution already needs (small) design enhancements. 

Does anybody see any problem to support such a proxy solution? 

- Georg

---

From: Scott Brim <[email-masked]>
Date: Mon, 09 Apr 2012 11:04:44 -0400

> Does anybody see any problem to support such a proxy solution? 

Personally,

  - This is simple but it assumes a particular proxy will always be
    on-path -- a difficult assumption, one that has been shot down in
    other WGs.

  - To deal with that you need extra awareness in the
    end client that it is using a proxy.

  - Once you have that awareness it is a small step to support a
    mobility proxy.

  - And once you allow that, the simplest protocol to use for
    communication between the endpoint and the proxy is MIP.  Just the
    HA part.  It's a solid protocol.  You can skip the exotic bits.  We
    have years of (limited) experience.  It solves the MPTCP proxy
    problem _and_  provides support for at least one kind of legacy
    mobility.  MPTCP is a fine make-before-break supporting protocol
    for mobility, at the appropriate layer as well.

Scott

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 9 Apr 2012 10:34:18 -0500

Scott,

The "simplest MPTCP proxy scenario" supports a very relevant use case where the proxy resides on the 3G/4G operator's core network. 

This facilitates incremental deployment of end-host-based MPTCP, supports both mobility AND multipath operation, and is middle-box-compliant. The signaling upgrade is very small.

IMPORTANT: While a "mobility-only" proxy can be realized very efficiently any proxy-upgrade to MPTCP should still aim for full multipath operation. "Mobility-only" operation should mainly be seen as a deployment facilitator.

MIPv6 has no evolution toward a "true" end-host based protocol (i.e. operation w/o HA), does not support multipath operation, has only limited middle-box compliance and only speaks IPv6.

- Georg

-----Original Message-----
From: Scott Brim [mailto:[email-masked]] 
Sent: Monday, April 09, 2012 11:05 AM
To: Hampel, K Georg (K Georg)
Cc: John Leslie; [email-masked]
Subject: Re: [multipathtcp] Re-chartering MPTCP Issue #2: Proxies

Personally,

Scott

---

From: John Leslie <[email-masked]>
Date: Tue, 10 Apr 2012 09:10:05 -0400

Hampel, K Georg (K Georg) <[email-masked]> wrote:
> 
> The "simplest MPTCP proxy scenario" supports a very relevant use case
> where the proxy resides on the 3G/4G operator's core network. 
> 
> This facilitates incremental deployment of end-host-based MPTCP,
> supports both mobility AND multipath operation, and is middle-box-
> compliant. The signaling upgrade is very small.

   I'm afraid I'm not following what benefit Georg sees beyond what is
already available by making a NAT box MPTCP-agile.

   No doubt there are benefits, but standardizing this would be time-
consuming; and I remain nervous about establishing any kind of control
path outside your own management realm.

   If Georg wants to pursue this, I recommend that he draft language
which addresses a limited case -- this open-ended "anything we might
describe as a proxy" language invites wandering in the weeds.

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 10 Apr 2012 08:31:03 -0500

John,

This "limited case" has already been described in:
http://tools.ietf.org/html/draft-hampel-mptcp-applicability-wireless-networks-00

which was discussed at IETF81 - Quebec City:
http://tools.ietf.org/wg/mptcp/minutes?item=minutes81.html

Further discussions took place here:
http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011

I'm reiterating on this simple but very powerful proxy scenario since some people apparently have not followed these discussions.

- Georg