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

Joe Touch <touch@isi.edu> Tue, 02 May 2017 17:06 UTC

Return-Path: <touch@isi.edu>
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 2928C126C26 for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 10:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Bq8Z7Hgjp3tA for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 10:06:27 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410A512EC5F for <multipathtcp@ietf.org>; Tue, 2 May 2017 10:03:30 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v42H2iD8028141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 May 2017 10:02:55 -0700 (PDT)
To: mohamed.boucadair@orange.com, Juliusz Chroboczek <jch@irif.fr>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <024285f9-3756-9b59-bda7-3c38079709f8@isi.edu>
Date: Tue, 2 May 2017 10:02:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/5mA0jo4qIhOQf6E401acFM152J4>
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 17:06:29 -0000

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