> On 19. jul. 2016, at 17.52, Joe Touch <to...@isi.edu> wrote: > > > > On 7/19/2016 8:49 AM, 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. > I was speaking to the broader point of this thread and generalizing > your point about multi-streaming to the multiple path case as well. > > (I didn't know if you felt that both cases should be handled the same > way or whether you were using multi-streaming as an easier case to argue)
I focused on multi-streaming now as an easier case to argue :-) Let’s focus on this one first and then get to multipath. Sorry for the mixup! Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
