Thanks, Mirja On Fri, Feb 09, 2018 at 01:42:32PM +0100, Mirja Kuehlewind (IETF) wrote: > 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] > >>> > >
-- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
