Thanks Mirja, also for our talk earlier today.
-10 just posted.
As discussed today, and to summarize for the thread here:
As changelog explains, i changed the wording of the multipath text to
be a set of requirements and not to suggest specific ways how to use
MPTCP. Without changing the scope & goal of the multipath text, this
was IMHO the correct approach because through the review from Mirja and
Yoshi it became clear that there is more work to be done before there
is a mutually agreeable solution. Which i had expected from the beginning,
but the text nevertheless became too suggestive of specific ways how to
leverage MPTCP that where non-agreeable. Fixed now!
[ Working for a vendor, i usually have to tell customers
"don't describe the solution, describe the requirements". Takes
sometimes longer to recognize when you are the customer. ]
Also added the fix about need for end-to-end encryption (as brought up
by BrianC earlier).
On Fri, Feb 02, 2018 at 10:00:34AM +0100, Mirja Kuehlewind (IETF) wrote:
> Hi Toerless,
> see below again.
> > Am 01.02.2018 um 20:30 schrieb Toerless Eckert <t...@cs.fau.de>:
> > 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.
> This is something that should not be done with MPTCP because that exactly not
> what MPTCP is meant for. In this case just use a standard TCP connection. And
> that???s my whole point. I see that there is a use case for MPTCP in you
> setup when fallback is needed but don???t use MPTCP if not needed and then
> don???t require changes to MPTCP that would make it behave like single TCP
> because that really not the design goal of 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.
> Yes, we really do not need to design the whole solution here. But I don???t
> want to discuss the use of MPTCP when it is not necessary to use MPTCP and
> more over I don???t want to phrase requirement for MPTCP that doesn???t make
> sense because it would be easier to just use TCP instead.
> >>> 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).
> Yes, those details really don???t need to go in the draft. I was just
> replying to something Michael said.
> >> 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.
> And this is exactly my point and where we disagree.
> > 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.
> I don???t this this should be a requirement for MPTCP and I don???t think
> this should be spell out in this draft as such because you can just use a TCP
> connection in this case. That???s the whole point.
> > 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 [
> >>> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on
> >>> rails [
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
> > --
> > ---
> > t...@cs.fau.de
Anima mailing list