> On 20. jul. 2016, at 10.27, Colin Perkins <[email protected]> wrote: > >> 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. > > 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. 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). Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
