Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Mon, 07 November 2016 15:56 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 1EA41129685 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 3en0iY9hvHgg for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:56:47 -0800 (PST)
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 D5E18129573 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 07:56:47 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uA7FuLQr003316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Nov 2016 07:56:23 -0800 (PST)
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Olivier.Bonaventure@uclouvain.be
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be> <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch>
From: Joe Touch <touch@isi.edu>
Message-ID: <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu>
Date: Mon, 7 Nov 2016 07:56:20 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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/YByv6Q9YR-dMj7fqz-kEPIjNLJA>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
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: Mon, 07 Nov 2016 15:56:49 -0000


On 11/7/2016 7:42 AM, Mirja Kühlewind wrote:
> Do you mean the MCP forwards the original SYN (and basically does nothing if the server supports MPTCP) or does the MCP terminate the TCP connection and start a new TCP connection with MP_CAPABLE towards the server?
>
> Mirja
If you're OK with needing to terminate a failed option exchange, then it
might be possible to use EDO in the SYN in its current form.

TCPM decided to prohibit that in the general case, but I could ask them
to allow that in very limited environments (but it could NEVER be
default on).

Note - the use cases I'm hearing appear to assume very strong knowledge
about the other end of the connection and the path. In that case, you
probably can skip most - if not all - of the 'negotiation' options and
just start using them during the SYN too. However, if you say "no, we
need to confirm", then you would not be able to use EDO inside the SYN.

Joe