HI Toerless,

thanks so much for these edits. Unfortunately I have one more question. And 
sorry again for the delay.

Why does your case 2 need an MPTCP connection instead of just opening a second 
separate TCP data plan connection (that of course fails when it fails..)?


> Am 27.01.2018 um 00:06 schrieb Toerless Eckert <t...@cs.fau.de>:
> On Fri, Jan 26, 2018 at 11:43:08AM +0100, Mirja Kuehlewind (IETF) wrote:
>> Hi Toerless,
>> sorry for my late reply but I spend only limited time on AD stuff on the 
>> telechat agenda was crowded this week.
> Thanks for all the hard work!
>> Okay that is fine. I mainly wanted to double-check as that was still not 
>> fully clear from the provided text. Can you maybe propose a slight rewording 
>> that explicitly say that there is this backup while using the word 
>> ???only??? above in the cited text seems to indicated differently.
> I wanted to take the full extend of your feedback into account, so
> rewrote the paragraph in question maybe a bit more than slightly
> (couldn't figure out a sane "slightly" ;-):
> - Moved up the last sentence about per-connection policy up front,
>  so the examples are more logical scoped.
> - Made the examples into three separate bullet points
>  and expanded them to hopefully eliminate the misunderstanding
>  wrt to backup.
> - Not only mentioning the fall back (backup), but also added
>  desirable behavior under recovery of preferred subflow path. 
>  (important for both 1) and 2).
> - explaining in bullet point 3) how this one is actually a
>  simple TCP connection (As you pointed out).
>  (whereas 1) and 2) rely on the MPTCP benefit of two subflows and address 
> signaling).
> -09 uploaded with this fix as well as fix for Yohi's comment.
> Diff:
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-09.txt
> Here is the changed paragraph:
> The above described behavior/policy for MPTCP must be controllable by 
> applications or libraries acting on behalf of applications.  APIs
> and/or data models for this control need to be defined. It should be
> sufficient to make these policies work on a per connection    
> basis, and not change during the lifetime of a connection for 
> different data items:
> 1) The policy for likely most connections would be to use the data-plane
>   subflow and fall back using the ACP subflow when the data-plane fails.
>   This could be the default. It reduces load on the ACP but would continue
>   to run connection traffic at likely reduced throughput when the
>   data-plane fails.  Ideally such connections would also revert back to
>   using a data-plane subflow once its connectivity recovers.
> 2) Connections for non-urgent bulk transers (for example most routine 
>   firmware updates or cached log collection) may use a policy where
>   the connection is made to fail when the data-plane fails or have
>   transfers suspend until another data-plane subflow can successfully
>   be built. This avoids over-taxing the ACP when the data plane fails. 
> 3) Connections for critical network configuration change operations 
>   known to impact the data-plane might want to only use the ACP and
>   could therefore map to a (non-MP)TCP connection.
> Cheers
>    Toerless
> m 22.01.2018 um 19:42 schrieb Toerless Eckert <t...@cs.fau.de>:
>>> Thanks, Mirja. Inline.
>>> On Mon, Jan 22, 2018 at 01:37:58PM +0100, Mirja Kuehlewind (IETF) wrote:
>>>> Hi Toerless,
>>>> thanks a lot for the updated text. I still have one little point I would 
>>>> like to discuss a bit further on this text:
>>>> "The above described behavior/policy for MPTCP must be controllable by     
>>>> applications or libraries acting on behalf of applications.  APIs  
>>>> and/or data models for this control need to be defined.  As outlined       
>>>> above, applications for example may choose to only perform transfers       
>>>> if the data-plane is actually available because of performance     
>>>> limitations of the GACP, so the application needs to be made aware if      
>>>> the setup of the data-plane subflow fails.  Or transfers may want to       
>>>> only use the GACP because the connection performs configuration    
>>>> changes that are likely known to bring down the data-plane.  It    
>>>> should be sufficient to make these policies work on a per connection       
>>>> basis, and not change during the lifetime of a connection for      
>>>> different data items.???
>>>> When you say that there is a need for an application to send data only on 
>>>> one path, today that???s not possible with MPTCP as you may fallback to 
>>>> the other path silently during the transmission. Yes, of course this could 
>>>> be changed and an extended interface could indicate this. 
>>>> So my question is still what the ???only??? really means in this text. If 
>>>> you???d like to just indicate a preference that might be okay. If you 
>>>> really want to rule out the possibility to fallback to the other path, 
>>>> then I don???t think you need MPTCP and two separate TCP connections would 
>>>> be the better option.
>>>> Does that make sense to you?
>>> Not really, the goal is always to leverage existing MPTCP signaling of
>>> addresses, indicating backup for flows, etc. I think two TCP flows would
>>> never be better:
>> Okay that is fine. I mainly wanted to double-check as that was still not 
>> fully clear from the provided text. Can you maybe propose a slight rewording 
>> that explicitly say that there is this backup while using the word 
>> ???only??? above in the cited text seems to indicated differently.
>> Thanks!
>>> The GACP address is the primary identifier of a device known in DNS.
>>> Data-Plane addresses can change over time subject to operator configuration
>>> and could also pose more of a security issue to be in DNS (GACP is isolated
>>> network).
>>> GACP performance may be quite low because some network device may 
>>> route/forward
>>> it in software. data-plane routing/forwarding is expected to be 
>>> fast/HW-accelerated.
>>> With MPTCP as suggested this gives for example:
>>> Initial subflow must use GACP because thats the only "known/stable address" 
>>> in DNS
>>> Then MPTCP signaling is used to indicate mutually the data-plane addresses
>>> and make GACP subflow backup.
>>> Then you transfer lets say a few Gigabyte of data (e.g.: firmware update) 
>>> which
>>> goes over data-plane.
>>> Then some uncorrelated error happens and data-plane fails. This particular 
>>> app
>>> should then fail because it would just slow down to insufferable slow across
>>> GACP and would overload software forwarding in GACP.
>>> In another application connection, fallback to GACP subflow for data if 
>>> dat-plane
>>> subflow fails is fine, but you would only prefer data-plane for performance.
>>> You could consider the GACP potential software only forwarding like a very 
>>> high
>>> cost of using it while data-plane is free.
>>> If i would just use 2 * TCP instead of MPTCP i would have to reinvent a lot 
>>> of
>>> MPTCP to get the address signaling etc. Right ?
>>> Cheers
>>>   Toerless
>>>> Mirja
>>>>> Am 17.01.2018 um 03:36 schrieb Toerless Eckert <t...@cs.fau.de>:
>>>>> Mirja, Yoshifumi
>>>>> I just posted -08: 
>>>>> https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt
>>>>> I have reworked the MPTCP text based on your threads feedback with
>>>>> the intention to fix errors and have it answer the questions/concerns 
>>>>> raised,
>>>>> but without otherwise changing the scope of it:
>>>>> - What are they key features making MPTCP interesting 
>>>>> - How could it be used to solve the stable-connectivity issue
>>>>> beyond the scope of this document
>>>>> - Describe the areas of specification work required
>>>>> - API/policy, control by apps
>>>>> - dealing with dual VRF addresses
>>>>> Please check diff in this URL (not complete diff of -08, just fix for 
>>>>> your discuss/comment):
>>>>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/14d5f9b66b8318bc160cee74ad152c0b926b4042/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/c02252710fbd7aea15aff550fb393eb36584658b/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-08.txt
>>>>> I hope this resolves your DISCUSS/comments. 
>>>>> Note that the term ACP was changed in the doc to GACP based on resolving 
>>>>> Alvaros discus. See:
>>>>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/08-01-alvaro-retana.txt
>>>>> Thank you
>>>>>  Toerless
>>>>> On Thu, Jan 11, 2018 at 03:42:53PM +0100, Mirja K?hlewind wrote:
>>>>>> Hi Toerless,
>>>>>> the point I'm wondering about is your point (b) below. Yes, you can
>>>>>> set the ACP subflow to backup but that would still mean that if the
>>>>>> other link fails, it would automatically switch over to the ACP
>>>>>> subflow (without exposing this to the upper layer). Is that what you
>>>>>> want? Because my understanding was rather that there are cases where
>>>>>> you'd probably would like to know over which link the OAM packets
>>>>>> where actually sent...?
>>>>>> Mirja
>>>>>> On 08.01.2018 22:06, Toerless Eckert wrote:
>>>>>>> Thanks, Mirja
>>>>>>> (a) If the systems socket API does not transparently make TCP sockets
>>>>>>> to use MPTCP, then you would want a shim library. According to
>>>>>>> draft-hesmans-mptcp-socket, this is be the case on Apple (iOS).
>>>>>>> (b) Making the ACP subflow not carry traffic after establishing the
>>>>>>> data plane subflow should easily be possible possible by setting its 
>>>>>>> MP_PRIO
>>>>>>> to backup.
>>>>>>> (c) How exactly to specify or implement the desired policy of only
>>>>>>> establishing a subflow between the ACP addresses and the data plane 
>>>>>>> addresses
>>>>>>> (but not full-mesh) seem to be a subject for further spec work. It could
>>>>>>> be defined as a specific in-MPTCP policy, or it could be done via a shim
>>>>>>> library (orthogonal to (a)). draft-hesmans-mptcp-socket might be 
>>>>>>> sufficient.
>>>>>>> But in general: i would like for this (informational!) draft to just 
>>>>>>> motivate
>>>>>>> the concept and not specify the solution: MPTCP would be a simple way to
>>>>>>> make "TCP" applications automatically "upgrade" from ACP to a 
>>>>>>> data-plane path
>>>>>>> and switch back when data-plane fails... because MP-TCP can signal the
>>>>>>> additional data-plane addresses, establish transparently another 
>>>>>>> subflow and switch
>>>>>>> traffic between the subflows - all by using the right shim-library+API 
>>>>>>> or
>>>>>>> in-MP-TCP address/subflow policies - and the ability to establish 
>>>>>>> subflows
>>>>>>> across two VRFs.
>>>>>>> Cheers
>>>>>>>  Toerless
>>>>>>> On Mon, Jan 08, 2018 at 05:18:54PM +0100, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>>>> Suggested replacement text last two paragraphs of 2.1.5:
>>>>>>>>> A (shim) library for aplications maps TCP connections to MPTCP 
>>>>>>>>> without the applications having to be aware of it.
>>>>>>>> It???s not the (shim) library/policy framework that opens/maps the TCP 
>>>>>>>> connection. MPTCP itself opens eventually multiple connections but 
>>>>>>>> exposes only one connection to the layer above. That means everything 
>>>>>>>> above MPTCP does not have any real control about which data is send 
>>>>>>>> over which connection.
>>>>>>>> A policy shim layer could only implement rules about which new 
>>>>>>>> subflows should be established when and what the priority is over 
>>>>>>>> which subflow data should be sent but it generally does not control 
>>>>>>>> which data is send of which flow. You can???t say I want this data to 
>>>>>>>> be sent over subflow one and this data to be sent over sub flow two.
>>>>>>>> I think what you want is actually a view on the different TCP 
>>>>>>>> connections and you try to use MPTCP only for announcing the other IP 
>>>>>>>> address but that is not what MPTCP meant to be.
>>>>>>>> Mirja
>>>>>>>>> Names in DNS use only the ACP IPv6 addresses of network devices. 
>>>>>>>>> Thererefore, the initial MPTCP subflow will use the ACP. After it is 
>>>>>>>>> operating, the shim libraries on both ends add their data-plane 
>>>>>>>>> address (MPTCP ADD_ADDR) and attempt to build a new subflow between 
>>>>>>>>> those addresses. If that (data plane) subflow is successfully built, 
>>>>>>>>> the shim libraries could shift all traffic over this subflow which 
>>>>>>>>> should be forwarded hardware accelerated by the network - and use the 
>>>>>>>>> ACP subflow across the ACP solely for signaling - beause it is most 
>>>>>>>>> resilient against failure.
>>>>>>>>> This MPTCP approach is only an outline and would need to be fully 
>>>>>>>>> speficied for interoperable implementations. It may also require 
>>>>>>>>> extensions to MP-TCP. This mechanism must not be used without 
>>>>>>>>> providing for encryption of subflows not running across the ACP.
>>>>>>>>>>> Brian: ... can not use capital MUST NOT in an information draft (i 
>>>>>>>>>>> think)
>>>>>>>>> Cheers
>>>>>>>>> Toerless
>>>>>>>>> On Mon, Jan 08, 2018 at 11:30:30AM +0100, Mirja Kuehlewind (IETF) 
>>>>>>>>> wrote:
>>>>>>>>>> Hi Micheal,
>>>>>>>>>> to clarify one part below:
>>>>>>>>>>> Am 05.01.2018 um 23:30 schrieb Michael Richardson 
>>>>>>>>>>> <mcr+i...@sandelman.ca>:
>>>>>>>>>>> Mirja Kühlewind <i...@kuehlewind.net> wrote:
>>>>>>>>>>>> "DNS naming is set up to provide the ACP IPv6 address of network
>>>>>>>>>>>> devices.  Unbeknownst to the application, MPTCP is used.  MPTCP
>>>>>>>>>>>> mutually discovers between the NOC and network device the 
>>>>>>>>>>>> data-plane
>>>>>>>>>>>> address and caries all traffic across it when that MPTCP subflow
>>>>>>>>>>>> across the data-plane can be built."
>>>>>>>>>>> Section 2.1.5 is discussion, it discusses ways in which the
>>>>>>>>>>> anticipated low performance (compared to what the box might do with 
>>>>>>>>>>> its
>>>>>>>>>>> hardware accelerated forwarding).
>>>>>>>>>>> If we have an application that needs the bandwidth of the native 
>>>>>>>>>>> hardware,
>>>>>>>>>>> the connection can be initated over the ACP (that's what would be 
>>>>>>>>>>> in DNS).
>>>>>>>>>>> One presumes that an MPTCP layer could then enumerate the available 
>>>>>>>>>>> IPs at
>>>>>>>>>>> each end and then start off additional flows on the other 
>>>>>>>>>>> destinations.
>>>>>>>>>> MPTCP adda an additional TCP flow but for the application that still 
>>>>>>>>>> looks like one flow. As I said I???m not sure if that is what you 
>>>>>>>>>> want.
>>>>>>>>>> Mirja
>>>>>>>>>>> The application would have to include application security, since 
>>>>>>>>>>> it would
>>>>>>>>>>> not be protected by the ACP.
>>>>>>>>>>> Perhaps MPTCP doesn't work this way.
>>>>>>>>>>>> However, I'm actually uncertain how this is supposed to work and 
>>>>>>>>>>>> what
>>>>>>>>>>>> "Unbeknownst to the application" should mean. If another address 
>>>>>>>>>>>> should be
>>>>>>>>>>>> signaled to the other host, this needs to be indicated by the 
>>>>>>>>>>>> application or at
>>>>>>>>>>>> least some kind of policy framework above MPTCP. Also MPTCP will 
>>>>>>>>>>>> by default use
>>>>>>>>>>>> both paths simultaneously while still looking like one connection 
>>>>>>>>>>>> to the
>>>>>>>>>>>> application, meaning the application has no control which path is 
>>>>>>>>>>>> used for
>>>>>>>>>>>> which traffic. I guess you can open a second subflow and then 
>>>>>>>>>>>> configure the
>>>>>>>>>>>> first subflow as backup path but I'm not sure if that's what you 
>>>>>>>>>>>> want (given
>>>>>>>>>>>> the application/policy framework will still not know which path is 
>>>>>>>>>>>> used)..?
>>>>>>>>>>>> Please provide more information about what the expected usage 
>>>>>>>>>>>> scenario is here.
>>>>>>>>>>> --
>>>>>>>>>>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>>>>>>>>>>> -= IPv6 IoT consulting =-
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Anima mailing list
>>>>>>>>>> Anima@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>>>>> -- 
>>>>>>>>> ---
>>>>>>>>> t...@cs.fau.de
>>>>> -- 
>>>>> ---
>>>>> t...@cs.fau.de
> -- 
> ---
> t...@cs.fau.de

Anima mailing list

Reply via email to