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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 27 March 2017 18:21 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 50976129567 for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 11:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 CG3qjNxOaYI5 for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 11:21:05 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA0A1293E3 for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 11:21:02 -0700 (PDT)
Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2AD9027992A for <multipathtcp@ietf.org>; Tue, 28 Mar 2017 03:21:00 +0900 (JST)
Received: by mail-ot0-f182.google.com with SMTP id 102so26411253otv.0 for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 11:21:00 -0700 (PDT)
X-Gm-Message-State: AFeK/H1qmfSxwtf912LG/vx1ss8b7V7YmNh6iTkTRyxriFMPfQD0JJ4S1iD0qa6k5jTMmQ9bIYhoNslYx1yXgg==
X-Received: by 10.157.59.118 with SMTP id z109mr11189248otb.193.1490638858405; Mon, 27 Mar 2017 11:20:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.41.137 with HTTP; Mon, 27 Mar 2017 11:20:58 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAO249yc3MOaPjBsmYqsZgW3AaxKmpA_wr2TxvgLZLwP6rf9dwA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 27 Mar 2017 11:20:58 -0700
X-Gmail-Original-Message-ID: <CAO249ydXsYv7TDXcfAF0gXxrDQocT_jqt2kRC5VVjFrik4CrqA@mail.gmail.com>
Message-ID: <CAO249ydXsYv7TDXcfAF0gXxrDQocT_jqt2kRC5VVjFrik4CrqA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a1140ccf2a4d0f5054bba675d
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Zanluye7b3ZsBjIZZpMP6pfpAZ0>
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 18:21:07 -0000

Hi Olivier, Med,

Thanks for the response. I have been thinking that it would be better if we
can classify our use cases so that we can have clear vision for what to
solve. Things I may want to classify is:
   a) solutions requires changes in only MPTCP or in TCP general
   b) solutions requires proxies to be on-path or solutions that work with
off-path proxy.

We can think about the solutions for a) if we think it's necessary, but I
am thinking that the proper venue for the discussion might not be this WG.

I think the approach Med mentioned requires the proxy to be on-path, so I
would like to classify it as an on-path solution.
I had some hard time to comprehend the proxy drafts and I think one reason
for that is it somehow mixes up on-path and off-path cases. I start
thinking separating docs for on-path and off-path solutions might be
helpful.
--
Yoshi

On Mon, Mar 27, 2017 at 8:06 AM, <mohamed.boucadair@orange.com> wrote:

> 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.
>
>
>