Re: [multipathtcp] q about on-path proxy

[Yoshifumi Nishida <[e-mail]>]

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, <[e-mail]> wrote:
>
> Re-,
>
> Thank you for the clarification.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Olivier Bonaventure [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
>