Re: [multipathtcp] q about off-path proxy (explicit mode)

<mohamed.boucadair@orange.com> Mon, 27 March 2017 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 26F46128854 for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 08:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.395
X-Spam-Level:
X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 U1uKGEipUB5B for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 08:06:31 -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 761F4129722 for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 08:06:30 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 09748C04A3; Mon, 27 Mar 2017 17:06:29 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id E059060062; Mon, 27 Mar 2017 17:06:28 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 17:06:28 +0200
From: <mohamed.boucadair@orange.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] q about off-path proxy (explicit mode)
Thread-Index: AQHSpWjpIG5mwHiqfkyKKBg/nUi2lqGoymbw
Date: Mon, 27 Mar 2017 15:06:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAO249yc3MOaPjBsmYqsZgW3AaxKmpA_wr2TxvgLZLwP6rf9dwA@mail.gmail.com>
In-Reply-To: <CAO249yc3MOaPjBsmYqsZgW3AaxKmpA_wr2TxvgLZLwP6rf9dwA@mail.gmail.com>
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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E41157OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/_vhwAC2U8XQgWZbQFHmFSbxXVpQ>
Subject: Re: [multipathtcp] q about off-path proxy (explicit mode)
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: Mon, 27 Mar 2017 15:06:35 -0000

Hi Yoshi,

Olivier already answered to many of your points. There are other communication scenarios not included in your list that we want to cover.

Below some additional comments.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Yoshifumi Nishida
Envoyé : samedi 25 mars 2017 08:08
À : multipathtcp
Objet : [multipathtcp] q about off-path proxy (explicit mode)

Hello,
Now, I am trying to understand off-path (explicit mode) scenarios.
In explicit mode, we need to tell the final destination to the proxy through MP_Convert Information Element. But, this requires mptcp connections. In order to clarify which cases can use this mode, I have drawn the following 7 cases.
I am wondering if we can support case 3) 4) 5) with explicit mode or not. Also, supporting case 6), 7) seems to be a bit unclear.
It would be great if some folks could clarify this.

-----------------------------------------------------------------------------


     C ... client,   S ... Server,  P ... Proxy,  MCIE ... MP_Convert Information Element
   ====   ... mptcp connection
   ----   ... tcp connection


single proxy cases

1)   C ========== P -------- S         : C tells S's addr to P by MCIE
2)   C ========== P ======== S         : C tells S's addr to P by MCIE
3)   C ---------- P ======== S         : How C tell S's address to P?
[Med] The communication between C and P relies on TCP. C does not need to supply any information to P for case 3. The client is not even aware about the presence of P in this case.

double proxy cases

4)   C -------- P1 ======== P2 ------- S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1. There is no need for an object to supply that information.

5)   C -------- P1 ======== P2 ======= S  : How C tell S's address to P1?
[Med] S is the destination IP address of the packets sent from C to P1.

6)   C ======== P1 ======== P2 ------- S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.  MCIE is not needed in the C-P1 leg.

7)   C ======== P1 ======== P2 ======= S  : C tells S's addr to P1 by MCIE and P1 forwards it to P2?
[Med] No. S is the destination IP address of the packets sent from C to P1.