Thanks! I think know we really captured everything. Thanks for writing this up clearly! Will release my discuss now!
Mirja > Am 06.02.2018 um 03:52 schrieb Toerless Eckert <[email protected]>: > > Thanks Mirja, also for our talk earlier today. > > -10 just posted. > > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-10.txt > > 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). > > Cheers > toerless > > > > 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 <[email protected]>: >>> >>> 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. >> >> Mirja >> >> >> >>> >>> 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
