> On 19. jul. 2016, at 18.06, G Fairhurst <[email protected]> wrote: > > On 19/07/2016, 17:49, 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. >> >> Cheers, >> Michael > I can agree that applications should be encouraged to let the system figure > out how best to do these things. > > A few applications will always want finer control (of QoS and flow > scheduling) - presumably because they believe they understand what they > actually need. I suggest even these apps can benefit from system-learned > information about what the network can actually offer.
Sounds like you’re suggesting to *not* expose these transport services too? I’d agree. We can’t make a “perfect” decision here, it’s a trade-off: this is the part of TAPS where we can’t work with simple rules anymore but we have to make some deliberate design choices. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
