IETF Logo Mail Archive

Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Joe Touch <touch@isi.edu> Mon, 24 April 2017 14:50 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 0C02A131644 for <multipathtcp@ietfa.amsl.com>; Mon, 24 Apr 2017 07:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 9-nXgHD2Doz7 for <multipathtcp@ietfa.amsl.com>; Mon, 24 Apr 2017 07:50:27 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 11458131577 for <multipathtcp@ietf.org>; Mon, 24 Apr 2017 07:49:21 -0700 (PDT)
Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3OEmift002033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2017 07:48:46 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@isi.edu>
X-Mailer: iPad Mail (14E304)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Mon, 24 Apr 2017 07:48:44 -0700
Cc: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <11026acd-8f91-ff42-299d-b646c19c953e@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <d53d6f13-f412-c42f-53a6-04637c7fef9b@isi.edu> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/T_-36biNHyFp9Z0465gExkB6KxQ>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Apr 2017 14:50:32 -0000

Med,

A proxy can operate at the conventional socket layer and would not have or need direct access to SYN segments. Any information needed to reconstitute the SYN at the upstream proxy could be retrieved in other ways.

You're pushing a split-TCP solution, one that (again, I repeat) the IETF has never sanctioned and I do not agree with.

Joe

> On Apr 24, 2017, at 1:23 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> Joe, 
> 
> Transforming a TCP connection into MPTCP connection will obviously need to access to SYNs to insert MPTCP options. 
> 
> This is the basic behavior of ** any ** MPTCP proxy.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joe Touch [mailto:touch@isi.edu]
>> Envoyé : vendredi 21 avril 2017 18:04
>> À : BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com;
>> multipathtcp@ietf.org
>> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>> 
>> Med,
>> 
>> I've made my position clear too.
>> 
>> I do not support this doc as MPTCP work.
>> 
>> I also call into question whether this is in-scope for MPTCP. MPTCP is
>> chartered to work within MPTCP - but this solution requires access to
>> raw incoming SYNs inside a different TCP connection, which is no longer
>> in-scope IMO.
>> 
>> Joe
>> 
>

v2.23.0 | Report a Bug | By Email