> 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? > 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. -- Colin Perkins https://csperkins.org/ _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
