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

<mohamed.boucadair@orange.com> Tue, 02 May 2017 08:45 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 46AF81314FA for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 01:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.501
X-Spam-Level:
X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, 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 PxUwY5KPZEcn for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 01:45:52 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF95131568 for <multipathtcp@ietf.org>; Tue, 2 May 2017 01:40:17 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id D60E920439; Tue, 2 May 2017 10:40:15 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.25]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id A719340079; Tue, 2 May 2017 10:40:15 +0200 (CEST)
Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM4C.corporate.adroot.infra.ftgroup ([fe80::347e:851c:671b:3eed%21]) with mapi id 14.03.0339.000; Tue, 2 May 2017 10:40:15 +0200
From: <mohamed.boucadair@orange.com>
To: Juliusz Chroboczek <jch@irif.fr>, Joe Touch <touch@isi.edu>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSwEx9woaOItK6k0i36wAJguoqRKHbAE4AgAAN1QCABa44YA==
Date: Tue, 2 May 2017 08:40:14 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <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> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <e96adf18-f116-f424-9067-74b38ced6eee@isi.edu> <87d1bw1je8.wl-jch@irif.fr> <c66fa996-ce5a-8e37-dd40-4364cdabb7ff@isi.edu> <874lx81fjd.wl-jch@irif.fr>
In-Reply-To: <874lx81fjd.wl-jch@irif.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/jcGvEC1JKpB5YlgdkrRmIFxDhUs>
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: Tue, 02 May 2017 08:45:54 -0000

Hi Juliusz, 

Yes, that's the point. 

We are leveraging on existing IETF endorsed behaviors (defined in BCPs). In particular, we are assuming this simplified state machine by the proxy: 

                    +----------------------------+
                    |                            |
                    V                            |
                 +------+   Client               |
                 |CLOSED|-----SYN------+         |
                 +------+              |         |
                     ^                 |         |
                     |TCP_TRANS T.O.   |         |
                     |                 V         |
                 +-------+          +-------+    |
                 | TRANS |          |  INIT |    |
                 +-------+          +-------+    |
                   |    ^               |        |
             data pkt   |               |        |
                   | Server/Client RST  |        |
                   |  TCP_EST T.O.      |        |
                   V    |           Server SYN   |
              +--------------+          |        |
              | ESTABLISHED  |<---------+        |
              +--------------+                   |
               |           |                     |
         Client FIN    Server FIN                |
               |           |                     |
               V           V                     |
        +---------+   +----------+               |
        |  C FIN  |   |  S FIN   |               |
        |   RCV   |   |    RCV   |               |
        +---------+   +----------+               |
            |             |                      |
        Server FIN      Client FIN            TCP_TRANS
            |             |                    T.O.
            V             V                      |
        +----------------------+                 |
        |   C FIN + S FIN RCV  |-----------------+
        +----------------------+ 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Juliusz Chroboczek
> Envoyé : vendredi 28 avril 2017 21:47
> À : Joe Touch
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> >>> [Med] The main point Joe is that the IETF has standard track documents
> >>> that specify a TCP state machine when NAT is used. We are leveraging
> >>> that state machine for the MPTCP proxy work.
> 
> >> I think that's an important point.
> 
> > And I think it is incorrect, at least for the split-TCP case.
> 
> Yes, I think that what Mohammed is saying is that the "plain mode proxy",
> as currently defined, requires NAT-style techniques.  I'd argue that this
> makes it neither plain nor a proxy.
> 
> -- Juliusz
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp