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. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
