Hi Toerless, I don’t think that’s how MPTCP works. See blow.
> Am 08.01.2018 um 16:47 schrieb Toerless Eckert <[email protected]>: > > Let me know what you think: > >>> 2.5.1 third to last paragraph:... >>> For example, a set-up for non-MPTCP aware applications could be as follows: >>> >>> 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] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
