Re: [multipathtcp] q about on-path proxy

[<[e-mail]>]

Hi Yoshi, all,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[e-mail]]
Envoyé : mercredi 22 mars 2017 23:07
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; 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, <[e-mail]<mailto:[e-mail]>> wrote:
>
> Re-,
>
> Thank you for the clarification.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Olivier Bonaventure [mailto:[e-mail]<mailto:[e-mail]>]
> > 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
>