Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Fri, 04 November 2016 14:54 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 1802E12951A for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level:
X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2YHG661TZTj9 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:54:05 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A6B1294A0 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 07:54:05 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id DC09C40667; Fri, 4 Nov 2016 15:54:03 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id ABD091A005B; Fri, 4 Nov 2016 15:54:03 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 15:54:03 +0100
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNqlERUtLqWz5O0GSJn2xeu0zS6DI54+w
Date: Fri, 4 Nov 2016 14:54:02 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAC89D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <DA4EE00C-A54A-45C0-95B1-72F59BE5134D@tik.ee.ethz.ch> <AE721A71-0B9C-4A05-94AE-C104318DCF7F@isi.edu>
In-Reply-To: <AE721A71-0B9C-4A05-94AE-C104318DCF7F@isi.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/_KEAwnjbDd34KBxbUwZmiVftY7g>
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:54:08 -0000

Re-,

There are already some generic proposals (e.g., SYN EOS), but IMHO those require an out of band SYN (second SYN) to extend the TCP option space, while the payload space of the original SYN can be used! Also, side effects of using two SYNs are to be yet evaluated. 

The use of a flag in the MP_CAPABLE does not mean that this will be specific to MPTCP. If we trust that MPTCP will be widely adopted in the future and all devices will be MPTCP-capable by default, then this feature will be used by tcpinc and long options that will be in the future. 

Cheers,
Med 

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe
> Touch
> Envoyé : vendredi 4 novembre 2016 15:40
> À : Mirja Kühlewind
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> +1
> 
> > On Nov 4, 2016, at 7:24 AM, Mirja Kühlewind
> <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> >
> > 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>om>:
> >>
> >> 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
> >
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp