On 7/19/2016 8:49 AM, Michael Welzl wrote: >> On 19. jul. 2016, at 17.40, Joe Touch <[email protected]> wrote: >> >> >> >> On 7/19/2016 5:27 AM, Michael Welzl wrote: >>> 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. >> I'm not sure I understand how an app can/should know about any of this. >> It strikes me as involving the app deep in "how" things are done in >> other layers, rather than indicating a preference on behavior it sees >> (it really shouldn't "see" any of this directly, IMO). >> >> I.e., this would be a good place to take a lesson from QoS - the key is >> to indicate a preference to the net based on "application visible >> behavior", not to try to map things so directly based on semantics. > This sounds like a misunderstanding, maybe I didn’t make myself clear enough > - because I think we agree: > an application can / should not know about any of this, IMO. It should just > see a communication channel. > > So mapping these channels onto a transport connection is what I thought a > TAPS system underneath the application could do, and the application won’t > need to be bothered. I was speaking to the broader point of this thread and generalizing your point about multi-streaming to the multiple path case as well.
(I didn't know if you felt that both cases should be handled the same way or whether you were using multi-streaming as an easier case to argue) Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
