Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 1 Jul 2016 09:01:01 +0200

Hello,
>
> In the paired MPTCP proxies mechanism, there is user's TCP session and there is also multipath TCP session. It is a TCP over TCP idea, correct?

No, there are three TCP connections in this scenario :

- one (regular) TCP connection between client and CPE
- one Multipath TCP connection between the CPE and the Concentrator
- one (regular) TCP connection between the Concentrator and the remote 
server

> As for TCP over TCP, the following page explains why an internal meltdown effect would take place due to the interaction between two leveled retransmission mechanisms.
> http://sites.inka.de/bigred/devel/tcp-tcp.html

This is a well known issue.

> Do we have solid solutions for this issue nowadays?

The solution is to terminate the TCP connections transparently. This is 
what most TCP optimisers used in mobile networks do already.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Fri, 1 Jul 2016 10:27:15 -0700

On 7/1/2016 12:01 AM, Olivier Bonaventure wrote:
> Hello,
>>
>> In the paired MPTCP proxies mechanism, there is user's TCP session
>> and there is also multipath TCP session. It is a TCP over TCP idea,
>> correct?
>
>> As for TCP over TCP, the following page explains why an internal
>> meltdown effect would take place due to the interaction between two
>> leveled retransmission mechanisms.
> The solution is to terminate the TCP connections transparently. This
> is what most TCP optimisers used in mobile networks do already.

Is there a current standard or BCP endorsing this practice?

AFAICT, it's in direct opposition of RFC1122. I hope we don't want to
create a new RFC that flies in the face of what few standards we have
unless we're prepared to revise those standards first.

"deployed in the wild" is not a sufficient justification, IMO.

Joe

---

From: Jordan Melzer <[email-masked]>
Date: Tue, 5 Jul 2016 09:47:55 -0600

Hi Joe,

The main RFC reference for performance enhancing proxies is here:
https://tools.ietf.org/html/rfc3135

It gives consideration to the end-to-end principle and describes deployments (current as of 2001).

Do you have an informational RFC (or other BCP) reference for routing-based approaches to multipathing individual-user traffic?

Re TCP over TCP approaches, if they could work, would you like them better than a proxy approach?  Eg, (untested) MP-DCTCP lower layer?

Jordan

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: July 1, 2016 01:27 PM
To: [email-masked]; Mingui Zhang; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

AFAICT, it's in direct opposition of RFC1122. I hope we don't want to create a new RFC that flies in the face of what few standards we have unless we're prepared to revise those standards first.

Joe

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 10:20:10 -0700

> https://tools.ietf.org/html/rfc3135

That's informational, not standards track.

I don't think it is appropriate to endorse the behaviors described in
that RFC in a standards-track protocol.

> Do you have an informational RFC (or other BCP) reference for routing-based approaches to multipathing individual-user traffic?
Informational RFCs are not BCPs.

I don't have such a reference or know whether one exists, but then
again, that's your challenge.

> Re TCP over TCP approaches, if they could work, would you like them better than a proxy approach?  Eg, (untested) MP-DCTCP lower layer?

I judge IETF approaches by the following criteria:
    - whether there is a problem that needs to be solved (or a new
capability that needs to exist)
    - whether the solution solves the problem (or provides the new
capability)
    - the impact of the solution on the rest of the Internet

You haven't convinced me of any of the above yet.

Joe