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 <t...@cs.fau.de>:
> > 
> > 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 <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.
> >> 
> >> 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  [
> >>>>> ]     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
> >>> 
> > 

-- 
---
t...@cs.fau.de

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to