Hi Toerless, sorry for my late reply but I spend only limited time on AD stuff on the telechat agenda was crowded this week.
See below. > Am 22.01.2018 um 19:42 schrieb Toerless Eckert <[email protected]>: > > > 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 <[email protected]>: >>> >>> 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 >>> - Disclaimer that THIS REQUIRES ADDITIONAL SPECIFICATION WORK >>> 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 >>>>>>>>> <[email protected]>: >>>>>>>>> >>>>>>>>> >>>>>>>>> Mirja Kühlewind <[email protected]> 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 <[email protected]>, Sandelman Software Works >>>>>>>>> -= IPv6 IoT consulting =- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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
