> On 20. jul. 2016, at 10.42, Colin Perkins <c...@csperkins.org> wrote: > > >> On 20 Jul 2016, at 10:38, Michael Welzl <mich...@ifi.uio.no> wrote: >> >>> >>> On 20. jul. 2016, at 10.27, Colin Perkins <c...@csperkins.org> wrote: >>> >>>> On 19 Jul 2016, at 18:06, G Fairhurst <go...@erg.abdn.ac.uk> wrote: >>>> On 19/07/2016, 17:49, Michael Welzl wrote: >>>>>> On 19. jul. 2016, at 17.40, Joe Touch<to...@isi.edu> 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. >>> >>> Agree - exposing system-learned knowledge is clearly useful. I’m all for >>> automating things where possible, but there are applications that can make >>> use of additional knowledge to tune transport to better suit the >>> application. Hide by default, sure, but allow tuning. >> >> So in TAPS it seems to me that we’ll ALWAYS have someone saying “but there >> can be a benefit if an application can do X, Y, Z”. >> And these always true statements. Everything that’s now there is there for a >> reason, so whatever you remove will always come with an example of an >> application that can make good use of it. In the end, we have the same API >> as today and nothing has been achieved. > > Surely you have a better API, with well-thought out hooks for tuning?
A good TAPS implementation should! For now, with our “minset” draft, TAPS is only identifying which things could be “hidden” (automatized). >> So: sure a good TAPS API should allow applications to tune everything. Let’s >> make this clear once and for all, for all things that we potentially >> “automatize”, “hide” or whatever you to call it. >> >> But: I do think the point here is to identify which things should be “hidden >> by default” (to stay with your language, it doesn’t really matter what we >> call it). > > Agree. I’m just reacting to “you’re suggesting to *not* expose these > transport services too? I’d agree” which suggests something a little > different. Ah. Ok - have to be careful with language… “not expose” is stricter than what I meant. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
