Hi, Toerless,

On Thu, Feb 1, 2018 at 12:34 PM, Toerless Eckert <t...@cs.fau.de> wrote:

> On Thu, Feb 01, 2018 at 12:14:54PM -0600, Spencer Dawkins at IETF wrote:
> > This is Mirja's Discuss thread, and MPTCP is her working group, and she
> > knows MPTCP better than I do, but I'm confused about one thing, as I'm
> > reading this discussion ...
> >
> [...]
>
> > If I'm understanding the discussion, the desire is to use MPTCP to handle
> > failover to another pre-established flow quickly, and Mirja's point is
> that
> > normal MPTCP would just use both flows - so, not actually failing over,
> but
> > if you provision for each flow to carry all your traffic, which you would
> > have to do in order to handle failover anyway, I'm not sure why it's bad
> to
> > let MPTCP do what it would do normally, and load-share across
> > overprovisioned paths.
>
> I have not seen Mirja rejecting the statement of the draft that we
> can make one path a backup (not written out in the draft: via MPTCP
> MP_PRIO).
>

I'll let her follow up here. What I was asking about, was (see next)


> > Is that the discussion people think they're having?
>
> I think Mirja is trying to do due diligence that the problem can not be
> solved with just TCP, and i may not have been doing textually a good enough
> job highlighting how the need of an MPTCP like signaling for additional
> addresses (data-plane addresses) is necessary when you only have the
> GACP address in DNS but actually prefer to use the data-plane (see -09
> draft version, MPTCP options 1), 2)).
>

Thanks, that's helpful.

I do see the due diligence (she's a diligent AD), but I thought Mirja was
(also?) concerned that the draft was assuming that MPTCP could be made to
handle two paths in failover mode, when it actually doesn't work that way.
Perhaps I was misreading (at least some of the conversation happened while
I was in and out of China, and that never helps me do e-mail).

But I'll let you two keep typing :-)

Spencer


> Cheers
>     Toerless
>
> > Thanks,
> >
> > Spencer, the irresponsible AD, in this case ...
> >
> >
> > > > If all data-plane flows fail, then it might suspend
> > > > traffic.
> > >
> > > That will not happen with MPTCP; it will fail back to use the ACP
> > > connection (if there is a subflow for it).
> > >
> > > >
> > > > I think that there is some advantage to starting the connection on
> the
> > > ACP,
> > > > because:
> > > >  a) no TCP SYN listener on the data-plane interface(s) reduces attack
> > > >     surface (assuming NOC->router initialized connections, but the
> same
> > > >     argument applies to keeping the NOC devices isolated)
> > >
> > > Also with MPTCP you need a TCP SYN lister on the remote data-plane
> > > interface because creating a MPTCP subflow means sending a TCP SYN
> with an
> > > MPTCP option.
> > >
> > >
> > > >
> > > >  b) the IP addresses of the router on the data-plane might be hard to
> > > know
> > > >     in advance, being subject to routing algorithms and address
> > > assignment
> > > >     ASAs. Also some interfaces might exist only with LL addresses
> until
> > > the
> > > >     need to grow a GUA occurs.
> > > >
> > > >     The ACP addresses are essentially locked down by being embedded
> in
> > > >     certificate DNs. (see the ACP draft).  That also means that a TLS
> > > >     connection to the router will be validatable by the router's
> domain
> > > >     certificate, while the (stable? temporary?) address assigned on
> the
> > > dataplane
> > > >     interfaces will not.
> > >
> > > What I???m basically proposing is that you use MPTCP for case 1 (data
> that
> > > needs a fallback to the ACP connection) but for all other transmission
> > > (that should be done only over one of the paths, either data plane or
> ACP),
> > > you have additional plain TCP connections to use. You can still add an
> > > interface to MPTCP to extract the IP address information you need to
> start
> > > these additional connections.
> > >
> > > Mirja
> > >
> > > >
> > > > So that's what MPTCP gets us: the ability to start on the ACP, do
> > > security,
> > > > and then move the bulk traffic to another place.
> > >
> > > >
> > > > --
> > > > ]               Never tell me the odds!                 | ipv6 mesh
> > > networks [
> > > > ]   Michael Richardson, Sandelman Software Works        | network
> > > architect  [
> > > > ]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> > > rails    [
> > > >
> > >
> > >
>
> --
> ---
> t...@cs.fau.de
>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to