IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Fri, 12 May 2017 08:00 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 3B892129BD5 for <multipathtcp@ietfa.amsl.com>; Fri, 12 May 2017 01:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 Gra_B0KXlC-h for <multipathtcp@ietfa.amsl.com>; Fri, 12 May 2017 01:00:44 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDACA128B37 for <multipathtcp@ietf.org>; Fri, 12 May 2017 00:55:25 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4206F160278; Fri, 12 May 2017 09:55:24 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 1F80780062; Fri, 12 May 2017 09:55:24 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0339.000; Fri, 12 May 2017 09:55:23 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSw2YKv+r9thGs+02u0nwqTzixS6HwYoSw
Date: Fri, 12 May 2017 07:55:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E6FEEF@OPEXCLILMA3.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> <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <024285f9-3756-9b59-bda7-3c38079709f8@isi.edu>
In-Reply-To: <024285f9-3756-9b59-bda7-3c38079709f8@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/FBYS9hQGhNGNYrmUN-AbuFGHfVY>
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: Fri, 12 May 2017 08:00:46 -0000

Hi Joe, 

Sure. That's something we can consider.  

We are waiting for the chairs' summary for this consensus call. 

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:touch@isi.edu]
> Envoyé : mardi 2 mai 2017 19:03
> À : BOUCADAIR Mohamed IMT/OLN; Juliusz Chroboczek
> Cc : multipathtcp@ietf.org
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> Med,
> 
> Standard TCP state diagrams don't have many of the states you note
> below. The diagrams are Mealy machines, indicating the triggering event
> (timer expiration, user API action, or incoming segment) paired with a
> corresponding action (timer set, user API response, and/or outgoing
> segment). Also, standard TCP state diagrams all refer to a single
> socketpair association.
> 
> It would be useful to revise your diagram accordingly and include it and
> supporting references in the next update.
> 
> Joe
> 
> 
> On 5/2/2017 1:40 AM, mohamed.boucadair@orange.com wrote:
> > 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

v2.23.0 | Report a Bug | By Email