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. > > >
- [multipathtcp] q about off-path proxy (explicit m… Yoshifumi Nishida
- Re: [multipathtcp] q about off-path proxy (explic… Olivier Bonaventure
- Re: [multipathtcp] q about off-path proxy (explic… mohamed.boucadair
- Re: [multipathtcp] q about off-path proxy (explic… Yoshifumi Nishida
- Re: [multipathtcp] q about off-path proxy (explic… mohamed.boucadair
- Re: [multipathtcp] q about off-path proxy (explic… Yoshifumi Nishida
- Re: [multipathtcp] q about off-path proxy (explic… Olivier Bonaventure
- Re: [multipathtcp] q about off-path proxy (explic… mohamed.boucadair
- Re: [multipathtcp] q about off-path proxy (explic… Yoshifumi Nishida
- Re: [multipathtcp] q about off-path proxy (explic… philip.eardley