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 ...
On Thu, Feb 1, 2018 at 10:14 AM, Mirja Kuehlewind (IETF) < [email protected]> wrote: > Hi Michael, > > see below. > > > Am 01.02.2018 um 16:31 schrieb Michael Richardson <[email protected]>: > > > > > > Mirja Kuehlewind (IETF) <[email protected]> wrote: > >> Why does your case 2 need an MPTCP connection instead of just opening a > >> second separate TCP data plan connection (that of course fails when it > >> fails..)? > > > > I think the idea is that there is some long running connection; for > instance > > a log flow or a mirror port flow. Or maybe even an SDN control > connection. > > > > The case 2 I’ve been referring to is that: > > "2) Connections for non-urgent bulk transers (for example most routine > firmware updates or cached log collection) may use a policy where > the connection is made to fail when the data-plane fails or have > transfers suspend until another data-plane subflow can successfully > be built. This avoids over-taxing the ACP when the data plane fails.“ > > I think for non-urgent bulk transfers it would be no problem to open a new > TCP connection, send the data, and close it again. > > > > I believe (but I could be wrong) that MPTCP would allow a router that has > > multiple data-plane circuits to (pre-)establish those flows and then > quickly > > switch to them. > > You can also pre-establish normal non-MPTCP connections (and send > keep-alives); there is no difference or advantage when using MPTCP. > However, I don’t think you need that for non-urgent bulk transfers. > 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. Is that the discussion people think they're having? 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 [ > > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
