Re: [multipathtcp] q about on-path proxy

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 22 March 2017 22:07 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 CB110129A8F for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 15:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 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] 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 xgNU6yATY-wI for <multipathtcp@ietfa.amsl.com>; Wed, 22 Mar 2017 15:07:14 -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 CDE0C129430 for <multipathtcp@ietf.org>; Wed, 22 Mar 2017 15:07:13 -0700 (PDT)
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5F3A529C3CD for <multipathtcp@ietf.org>; Thu, 23 Mar 2017 07:07:11 +0900 (JST)
Received: by mail-oi0-f45.google.com with SMTP id w81so56013072oig.1 for <multipathtcp@ietf.org>; Wed, 22 Mar 2017 15:07:11 -0700 (PDT)
X-Gm-Message-State: AFeK/H24sh1eePaZyBjdinnCmy+6Tf7sXBGLIAFW7XL5rtdvXj8E1qJDpt+3GflWEdX1wtpfRz4hibgmzHorEw==
X-Received: by 10.202.87.13 with SMTP id l13mr20566017oib.182.1490220429955; Wed, 22 Mar 2017 15:07:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.41.137 with HTTP; Wed, 22 Mar 2017 15:07:09 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E3C5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CAO249ydsuoAUn0y6yo62OM8mdp_AfyS1cA+patgQ84ata5piXw@mail.gmail.com> <a5ae92e4-c0c9-96c6-a575-f23891189087@uclouvain.be> <787AE7BB302AE849A7480A190F8B933009E37584@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ee22e83a-464e-f3a1-3d48-15043bcd6f74@uclouvain.be> <787AE7BB302AE849A7480A190F8B933009E3C5EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Wed, 22 Mar 2017 15:07:09 -0700
X-Gmail-Original-Message-ID: <CAO249yc6KkvxKG3g5NzLguZZfEfGrvG1qFfvXL0WNwzECWdrLg@mail.gmail.com>
Message-ID: <CAO249yc6KkvxKG3g5NzLguZZfEfGrvG1qFfvXL0WNwzECWdrLg@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a113acbfc5d5e17054b58fbcc
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/USW11m9lvd14BqUp2jGtJMvacfc>
Subject: Re: [multipathtcp] q about on-path proxy
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: Wed, 22 Mar 2017 22:07:17 -0000

Hi Med, Olivier,

Thanks for the response. I think I got basic idea.  Now I have other
questions..
I feel on-path mode a bit more complex than off-path mode.

1:  I am thinking that when uMCP intercept the packet from C, we can send
MP_Convert Information Element to dMCP.
    (and dest will be dMCP instead of S)
    We don't need to use source routing and spoofing techniques on dMCP in
this approach, which looks simpler to me.

2: I am wondering how a sender will use MP_PREFER_SIGNAL.
    In my understanding, the possible use cases would be:
         a) A sender knows the receiver doesn't support MPTCP, but it still
wants to utilize MPTCP in some portions of path.
             In this case, it seems to me that we presume the existence of
MCP.
             If so, why we cannot use explicit mode (off-path mode) here?

         b) A sender not sure if the receiver supports MPTCP or not. But,
even if the receiver doesn't support MPTCP, it wants to use MPTCP in some
portions of path at least.
            In this case, uMCP will intercept packets and split the
connection regardless of whether the receiver supports MPTCP.
            The sender cannot know if the receiver supports MPTCP or not
because MCP works transparently.
            So, it can never learn about the receiver.
            If I think this way, it seems MP_PREFER_SIGNAL is not
beneficial when the receiver supports MPTCP.

--
Yoshi



On Wed, Mar 22, 2017 at 3:31 AM, <mohamed.boucadair@orange.com> wrote:
>
> Re-,
>
> Thank you for the clarification.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]
> > Envoyé : mercredi 22 mars 2017 11:13
> > À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida; multipathtcp
> > Objet : Re: [multipathtcp] q about on-path proxy
> >
> > Med,
> >
> >
> > >         +------- R4 ---- R5 --------+
> > > C --- uMCP ---- R1 ---- R2 ------ dMCP ---- R6 --- R7 --- S
> >
> >
> >
> > >>> Also, in the two proxy scenario, does the downstream MCP have to be
> > >>> on-path?
> > >>
> > >> If the downstream MCP is on path, then it does not have to include
any
> > >> NAT function which is beneficial from an operational viewpoint.
> > >>
> > >>
> > >
> > > [Med] Perhaps I misunderstood your point but DNAT/SNAT are still
needed
> > for subsequent subflows even for the implicit case. Think about subflows
> > that are placed with a destination address set to the one of the MCP and
> > with a distinct source IP address than the one used to place the initial
> > subflow.
> >
> > By no NAT, I mean that all the packets between the client and the server
> > that the operator would observe on the R1-R2 path or the R6-R7 path have
>
> [Med] For the R6-R7 leg, this is valid for all MCP deployments with
source address/prefix preservation.
>
> > C/S as source/destination addresses. This means that the existing
> > techniques that are used for logging, traffic control or monitoring that
> > depends on addresses can be reused without any modification.
>
> [Med] Agree, if these functions are located in the R1-R2 leg. Some
adjustments may be needed (Legal Intercept, for example), but that is out
of scope.
>
> >
> > When the uMCP creates a subflow towards the dMCP, it uses other
> > addresses than C and S, but these addresses are invisible to both the
> > client and the final server.
>
> [Med] Yes, this is the SNAT/DNAT I mentioned.
>
> >
> > Olivier
>