Thanks - I agree, it’s on the agenda for tomorrow’s MPTCP session, and TAPS is the day after, which fits nicely.
Note, I phrased this controversial on purpose to generate a bit of list discussion: “abstracting away” something like usage of multiple paths should get some people to disagree?! Regarding the primitives we have so far, there doesn’t seem to be a compelling need for a TAPS system to expose them to an application I think. (again, such abstraction always comes with loss of some control - at one end of this, you want to be in control of which transport protocol is used, which we don’t want here). Decisions need to be made... Multi-streaming seems to me to be an easier case: I can’t see any reason why an application would need to be in control of this. Mapping communication channels between the same end hosts onto the same transport connection (whatever protocol provides it) should always be beneficial. Cheers, Michael > On 19. jul. 2016, at 13.02, Mirja Kühlewind <[email protected]> > wrote: > > Hi Michael, hi all, > > I believe there is actually quite a bit of discussion currently in MPTCP > about how important it probably is to have an interface to the application > and get input about upper layer preferences. Maybe ask on the mptcp list for > input? > > Mirja > > >> Am 19.07.2016 um 09:49 schrieb Aaron Falk <[email protected]>: >> >> Hi Michael- >> >> It seems to me that one could answer the question separately whether the >> upper layer should be able to control the use of multi-streaming or >> multi-paths vs. know whether multi-streaming or multi-paths are in use. I >> would think that there no reason to hide this information from apps. would >> you agree? >> >> --aaron >> >> On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl <[email protected]> wrote: >> Hi, >> >> draft-gjessing-taps-minset-02 suggests that all transport service >> features related to multi-streaming and usage of multiple paths are >> “automatable”. The rationale is given in Section 4: >> https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4 >> (this particular section says “removed” which is a mistake, to be fixed >> in the next update; sorry! - read as “classified as automatable”) >> >> Note that abstraction always comes with loss of some control, that’s >> inevitable. It has to hurt a little bit :-) >> - our thinking is that none of these transport service features require >> application-specific knowledge and hence shouldn’t be exposed. >> >> Thoughts? >> >> Cheers, >> Michael >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps >> -- >> --aaron >> >> =====Short message from my phone===== >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
