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
>>> 
> 

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

Reply via email to