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

Joe Touch <touch@isi.edu> Fri, 01 July 2016 17:28 UTC

Return-Path: <touch@isi.edu>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1075812D75C for <multipathtcp@ietfa.amsl.com>; Fri, 1 Jul 2016 10:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsQT2E5bx9sm for <multipathtcp@ietfa.amsl.com>; Fri, 1 Jul 2016 10:28:09 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10C012D66D for <multipathtcp@ietf.org>; Fri, 1 Jul 2016 10:28:09 -0700 (PDT)
Received: from [128.9.184.82] ([128.9.184.82]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u61HRHne014772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Jul 2016 10:27:17 -0700 (PDT)
To: Olivier.Bonaventure@uclouvain.be, Mingui Zhang <zhangmingui@huawei.com>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
References: <CAC8QAccht1nMP95HVdP6YcqJfxNryvDbhaK=LY0LcW5-JKM82A@mail.gmail.com> <e597f6bc66d24c679edee2121ae7fc38@rew09926dag03b.domain1.systemhost.net> <4552F0907735844E9204A62BBDD325E787CE22C1@NKGEML515-MBX.china.huawei.com> <68c2382a-74c9-1999-e8d4-e5aceccbf4db@uclouvain.be>
From: Joe Touch <touch@isi.edu>
Message-ID: <5776A7F3.1000906@isi.edu>
Date: Fri, 1 Jul 2016 10:27:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <68c2382a-74c9-1999-e8d4-e5aceccbf4db@uclouvain.be>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u61HRHne014772
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/zSNCL6iYGqRk-Qc1XV0sEMpTxts>
Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 17:28:11 -0000


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?
>
> 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.

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