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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 27 March 2017 21:18 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 8BC40126DEE for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 14:18:23 -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_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 JoGUf0kdayRq for <multipathtcp@ietfa.amsl.com>; Mon, 27 Mar 2017 14:18:21 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE8F12967D for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 14:18:18 -0700 (PDT)
Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F25C629C5A5 for <multipathtcp@ietf.org>; Tue, 28 Mar 2017 06:18:16 +0900 (JST)
Received: by mail-ot0-f176.google.com with SMTP id 102so29665042otv.0 for <multipathtcp@ietf.org>; Mon, 27 Mar 2017 14:18:16 -0700 (PDT)
X-Gm-Message-State: AFeK/H1B5W5x94CxIKSGo1ZTcOx1FjF5KehIhG5AUwM7PwZTSJ4QNkmmhj7pVxMENz3Zt8m/b3t67/LHwyNeCA==
X-Received: by 10.157.61.202 with SMTP id l68mr13769062otc.242.1490649495679; Mon, 27 Mar 2017 14:18:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.41.137 with HTTP; Mon, 27 Mar 2017 14:18:15 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E41571@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAO249yc3MOaPjBsmYqsZgW3AaxKmpA_wr2TxvgLZLwP6rf9dwA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009E41157@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249ydXsYv7TDXcfAF0gXxrDQocT_jqt2kRC5VVjFrik4CrqA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009E41571@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 27 Mar 2017 14:18:15 -0700
X-Gmail-Original-Message-ID: <CAO249ydRS9de35P12y_mp3wvtF4UPy__GCPBR3+uuZHfDwQKzw@mail.gmail.com>
Message-ID: <CAO249ydRS9de35P12y_mp3wvtF4UPy__GCPBR3+uuZHfDwQKzw@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=001a11492f9aacce65054bbce1aa
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/FSi-RwKhgqb_PLc7dirF31kc0Ag>
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 21:18:24 -0000

Hi Med,

On Mon, Mar 27, 2017 at 12:32 PM, <mohamed.boucadair@orange.com> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
> *Envoyé :* lundi 27 mars 2017 13:21
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Yoshifumi Nishida; multipathtcp
> *Objet :* Re: [multipathtcp] q about off-path proxy (explicit mode)
>
>
>
> 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.
>
> [Med] I’m not sure to follow you here. What I described is aligned with
> the target dual proxy case (https://tools.ietf.org/html/
> draft-nam-mptcp-deployment-considerations-01#section-4.2): the first
> proxy is embedded on a CPE. There is no technical problem there to
> intercept the traffic to be proxyied given that the CPE sees all the
> traffic.
>

Well, this classification might be a bit different from the way described
in the draft.
What I meant for off-path (explicit) case is the cases where the proxy is
not on the path between client and server. No more and no less.
So, the dest address of the packets from client should be proxy's address.
(Otherwise, there's no way for proxies to fetch the packets)

I have thought it may be simpler if we think in this way rather than
thinking about CPEs.


>
>
> 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.
>
> [Med] There are a lot of commonalities between these two modes. The main
> difference is how to make involve the MCP into a connection.
>
>
This is just an idea. If we think we can proceed proxy ideas in the current
form, it's fine. But, I just would like to explore several possibilities.
--
Yoshi