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

Reply via email to