Re: [multipathtcp] q about on-path proxy

<mohamed.boucadair@orange.com> Thu, 23 March 2017 07:34 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 61C4612D574 for <multipathtcp@ietfa.amsl.com>; Thu, 23 Mar 2017 00:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.394
X-Spam-Level:
X-Spam-Status: No, score=-5.394 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, URIBL_BLOCKED=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 Q3lEiNw27DQn for <multipathtcp@ietfa.amsl.com>; Thu, 23 Mar 2017 00:34:24 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FB912E870 for <multipathtcp@ietf.org>; Thu, 23 Mar 2017 00:34:24 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id CDFF51805D4; Thu, 23 Mar 2017 08:34:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 95B9F1A00A1; Thu, 23 Mar 2017 08:34:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 08:34:22 +0100
From: <mohamed.boucadair@orange.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] q about on-path proxy
Thread-Index: AQHSo1irA/IADhYEd0SS7R3GWgbQkqGiAVxA
Date: Thu, 23 Mar 2017 07:34:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E3F48E@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> <CAO249yc6KkvxKG3g5NzLguZZfEfGrvG1qFfvXL0WNwzECWdrLg@mail.gmail.com>
In-Reply-To: <CAO249yc6KkvxKG3g5NzLguZZfEfGrvG1qFfvXL0WNwzECWdrLg@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.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E3F48EOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/S_gR0bx1w7AC087m3qSATmD_Wm8>
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: Thu, 23 Mar 2017 07:34:27 -0000

Hi Yoshi, all,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
Envoyé : mercredi 22 mars 2017 23:07
À : BOUCADAIR Mohamed IMT/OLN
Cc : Olivier.Bonaventure@uclouvain.be; multipathtcp
Objet : Re: [multipathtcp] q about on-path proxy

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.
[Med] The dual proxy case is the trivial case. Transforming a TCP connection into an MPTCP one assumes there is an on-path node that can handle the MTPCP connection appropriately. In order to distinguish native connections (e.g. MPTCP connections issued from a node located behind the uMCP) from proxied one, the MP_PREFER_PROXY signal is supplied to the dMCP as a trigger to “track” that connection.

             If so, why we cannot use explicit mode (off-path mode) here?
[Med] The explicit mode can be used, instead. There are deployment trade-offs that need to be considered. As an editor of the document, I’m trying to be neutral on this.

         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.
[Med] The uMCP behavior is policy-based. If it is instructed to intervene for native connections, it will do so. Otherwise, an MPTCP connection received from a host located in the LAN will be forwarded upstream without any modification (that is without any assistance from the MCP).

            The sender cannot know if the receiver supports MPTCP or not because MCP works transparently.
[Med] It can. An example of the single proxy case is provided in https://datatracker.ietf.org/doc/html/draft-nam-mptcp-deployment-considerations-01#section-5.6.1:

    ___________________
   / Host-based Model  \
   \___________________/

   +----+                     +-----+                     +--+
   | H1 |                     | MCP |                     |RM|
   +----+                     +-----+                     +--+
   h1@h2@                       mcp@                       rm@
    | |                          |                          |
    | |src:h1             dst:rm@|src:h1             dst:rm@|
    | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>|
    | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===|
    | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>|
    | | __________________________________________________  |
    | |/            Secondary subflow                      \|
    | |=====================SYN+MP_JOIN====================>|
    | |<===================SYN/ACK(MPJOIN)==================|
    | |=====================ACK(MP_JOIN)===================>|
    | |                       ...                           |


      Figure 15: Sample Connection Establishment with MCP Withdrawal
                              (Implicit Mode)
            So, it can never learn about the receiver.

[Med] It can. See the theoretical example provided above.

            If I think this way, it seems MP_PREFER_SIGNAL is not beneficial when the receiver supports MPTCP.
[Med] Even if the receiver is MPTCP-capable, involving the MCP may be beneficial in some cases (discussed in draft-nam-*):

·         Some of the receiver’s network attachments may be subject to a volume quota: because the server does not have this visibility, a server sending the traffic aggressively on such interfaces will lead to exhaust the quota rapidly.

·         Communicating with IPv4-only receivers, but the sender is connected to an IPv6-only network.



--
Yoshi



On Wed, Mar 22, 2017 at 3:31 AM, <mohamed.boucadair@orange.com<mailto: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<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
>