On Thu, Feb 01, 2018 at 05:14:58PM +0100, Mirja Kuehlewind (IETF) wrote:
> > 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).
Right. This is one of the pieces that i think would require additional
spec/extension to MPTCP - or could be handled by a shim library
that gets enough notificatations from MPTCP.
I was hoping we could move discussions about the "howto to an appropviate
draft in the MPTCP WG, eg: the to-be-renewed socket draft i mentione din
before.
> > 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.
The data-plane subflow MPTCP SYN/ACK can ony happen after the GACP
subflows ADD_ADDR, so one should be able to enable selective filtering
of data-plane SYN packets based on the address learned from the ADD_ADDR.
Can we somehow move all this discussion as mentioned above over to
some good (hopefully standards track) target draft in MPTCP ?
Stable connectivity is really just the informative use-case discussion
draft and should be read as a requirements draft containing a
high level description of the reasons why & how to use & expand MPTCP
(and/or shim library).
> 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.
See my previous reply why i think there is no difference between 1) and
2) re the need to leverage MPTCP. As said above, the main difference IMHO
is that "suspending or aborting" the connection upon failure of a subflow
is seemingly new and would require additional work for MPTCP.
Cheers
Toerless
> 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
> > [
> > ] [email protected] http://www.sandelman.ca/ | ruby on rails
> > [
> >
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
