Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Tue, 08 November 2016 15:06 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 17BC8129C98 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 07:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 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, 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 cY0nQgoSN6MM for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 07:06:31 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475D51296DF for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 07:06:31 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A917F2DC17E; Tue, 8 Nov 2016 16:06:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1981827C08C; Tue, 8 Nov 2016 16:06:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 16:06:29 +0100
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOc1MnemdljzUmEGiGID3gGUCC6DPKmIg
Date: Tue, 8 Nov 2016 15:06:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE31D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <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> <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu> <00ba6ab8-8fbf-ab19-b996-b84b87ad5520@isi.edu> <F9AAAF6C-DF82-412E-9C88-9043CC1EC3AA@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE088@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ca2610f2-4f1b-5123-1e6e-697dfbe7cdc7@isi.edu>
In-Reply-To: <ca2610f2-4f1b-5123-1e6e-697dfbe7cdc7@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
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/9_cLHtnMgzgLgNUQpPp4tPRUkPI>
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: Tue, 08 Nov 2016 15:06:33 -0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:touch@isi.edu]
> Envoyé : mardi 8 novembre 2016 15:35
> À : BOUCADAIR Mohamed IMT/OLN; Mirja Kühlewind;
> Olivier.Bonaventure@uclouvain.be
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi, Med,
> 
> 
> On 11/8/2016 2:07 AM, mohamed.boucadair@orange.com wrote:
> > Joe,
> >
> > I'm inserting the full text of that section here:
> >
> > ====
> >          4.2.2.5  TCP Options: RFC-793 Section 3.1
> >
> >             A TCP MUST be able to receive a TCP option in any segment.
> >             A TCP MUST ignore without error any TCP option it does not
> >             implement, assuming that the option has a length field (all
> >             TCP options defined in the future will have length fields).
> >             TCP MUST be prepared to handle an illegal option length
> >             (e.g., zero) without crashing; a suggested procedure is to
> >             reset the connection and log the reason.
> > ====
> >
> >    The proposed design for the MP_CONVERT option does not violate that
> >    text, IMO.  I'm listing here the design approaches that we considered
> >    so far:
> >
> >       (1) no change to MP_CAPABLE: MPTCP proxies are prepared by design
> >       to look at the payload of SYN to retrieve MP_CONVERT options.
> >
> >       *  MP_CONVERT options are inserted in the payload of a SYN that
> >          includes MP_CAPABLE.
> >       *  If the remote peer does not support MPTCP, the connection will
> >          be reverted to TCP according to the base MPTCP specification.
> ...
> Please explain. If there is option information in the SYN data, then a
> legacy peer is allowed to keep that data (and ACK it) in the SYN ACK.
> 
> So now it has option info that it interprets as data.

[Med] But a legacy node is not allowed to pass it to the application till the 3WHS is completed. https://tools.ietf.org/html/rfc793#section-3.4 says the following:

  Several examples of connection initiation follow.  Although these
  examples do not show connection synchronization using data-carrying
  segments, this is perfectly legitimate, so long as the receiving TCP
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                   
  doesn't deliver the data to the user until it is clear the data is
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  valid (i.e., the data must be buffered at the receiver until the
  connection reaches the ESTABLISHED state).  The three-way handshake
  reduces the possibility of false connections.

 You can't undo
> that unless you RST the connection, but that violates the cited text in
> RFC1122 above, i.e., you have created an option you cannot ignore by
> simply not ACKing it.

[Med] No error is encountered by the receiver side; we are safe at the front. RSTing the connection would not violate RFC1122, though. Further, this is encountered only at the first connection to a new MPTCP proxy.

> 
> 
> >      (2) change MP_CAPABLE to explicitly indicate that options are
> >       present in the SYN payload:
> >
> >       *  A flag in the MP_CAPABLE will be set to indicate to a remote
> >          peer that MP_CONVERT options are included in the payload.
> >       *  If the remote peer does not support MPTCP, the connection will
> >          be reverted to TCP as per base MPTCP specification.
> ...
> This has exactly the same problem.
> 
> It's not about "MUST ignore" - it's about "without error". Your approach
> creates an error in the TCP connection.

[Med] I agree that "without error" is an important aspect, but this text is about the receiver side. "it does not implement" does not make sense for the sender as it included the option in the first place! In the cases I mentioned above no error is declared by the receiver.  

> 
> Joe