Re: [multipathtcp] potential MPTCP proxy charter item

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 04 November 2016 14:24 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 38E3D129464 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GAuC1xuD0DRH for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:24:43 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630DD1288B8 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 07:24:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 21676D9314; Fri, 4 Nov 2016 15:24:42 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aHd-jkhU3Cke; Fri, 4 Nov 2016 15:24:41 +0100 (MET)
Received: from [192.168.178.33] (p5DEC2F5C.dip0.t-ipconnect.de [93.236.47.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B215BD930B; Fri, 4 Nov 2016 15:24:41 +0100 (MET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com>
Date: Fri, 04 Nov 2016 15:24:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA4EE00C-A54A-45C0-95B1-72F59BE5134D@tik.ee.ethz.ch>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.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> <e81c001b-ba6b-2990-9a62-09622e1339e1@uclouvain.be> <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/bQDO3USFTzyAugIs226F4OAVNvE>
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: Fri, 04 Nov 2016 14:24:46 -0000

Hi Olivier, hi all,

I really don’t buy our argument why you should develop such a mechanism for MPTCP only compared to a generic solution that could be used by all (existing and future) TCP extensions. MPTCP is not the only extension that could make use of this (tcpinc is another example) and I’m sure there will more mechanisms in future that would benefit from additional option space in the SYN. 

Mirja


> Am 04.11.2016 um 12:23 schrieb Alan Ford <alan.ford@gmail.com>:
> 
> Thanks for the comments, Olivier. If the working group thinks it would be a good idea, I would not be opposed to embedding some extended options support in MPTCP - as you say it seems a good chance to do so. I haven’t thought deeply yet about the various options below, all have their merits, but the flag sounds possibly easiest. Whatever extension was used, it could be particularly useful in the future for improved cryptographic handshakes.
> 
> This does not change my view, however, that MPTCP options should not be used for application-layer purposes, and that’s my main issue with MP_CONVERT as written - it’s a non-MPTCP-specific application-layer signal masquerading as a MPTCP option.
> 
> Regards,
> Alan
> 
>> On 4 Nov 2016, at 11:07, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
>> 
>> Alan,
>>> 
>>> Thank you for updating these drafts, I have been awaiting these with great interest!
>> ...
>>> To be clear - again - I have no issue with this work being done in MPTCP WG, it is “how to use proxies to increase deployment of MPTCP”. But this particular document is not MPTCP-specific; whether it is published here or elsewhere I don’t care, but it really shouldn’t’ be written as if it’s extending the MPTCP spec when there is no reason for it to be.
>>> 
>>> Finally, you earlier mentioned the possible effect on the base spec regarding a flag, but I see no mention of it in these docs.
>> 
>> Sorry for the late reply. The main problem with the current MPTCP draft is the length of the TCP options in the SYN segment. With network assisted MPTCP, we could need to encode one or two IP addresses inside TCP options in the SYN segment. With IPv4, this might be possible depending on the other options that are used. With IPv6, this becomes quickly a problem.
>> 
>> As we redefine MP_CAPABLE when moving to RFC6824bis, I think that we should try to design a generic solution to allow a SYN segment to carry long TCP options. This should be part of the Multipath TCP standard specification to ensure that it is future-proof and can be extended later.
>> 
>> Different designs are possible and some have been discussed in the TCPM working group. Instead of defining a specific option to allow longer options, I would suggest to include this feature directly inside Multipath TCP. This would be cleaner and Multipath TCP is anyway the TCP variant that mostly requires this feature. Here are a few possible designs to start the discussion :
>> 
>> - always force the TCP SYN segment containing MP_CAPABLE to contain options in the SYN payload. If all options can fit in the extended TCP header, then the payload only contains the TCP EOL option. If there are TCP options in the payload, then the last option is always the EOL option.
>> 
>> - add a flag to MP_CAPABLE option to indicate whether the SYN payload contains TCP options (terminated by EOL) or not. Same as above for encoding the options in the SYN payload
>> 
>> - add a length field to MP_CAPABLE option to indicate the number of bytes (or words) of the SYN payload that contain TCP options. In this case, we do not need to terminate the options in the payload with EOL.
>> 
>> If RFC6824bis could include a reasonable solution that allows to place TCP options in the SYN payload, we would make a huge step to ensure that MPTCP is future-proof and that it will be possible to extend it in the future. In the short term, the solution could be limited to networks where it is known that there are no middleboxes that interfere with TCP options, but this would be a strong message to middlebox vendors that they will need to support TCP options in the SYN payload in the future.
>> 
>> I won't unfortunately be able to attend the next IETF meeting in Seoul but I'd be happy to discuss this by email
>> 
>> 
>> Olivier
>> 
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp