> On 22. jul. 2016, at 10.27, Anna Brunstrom <[email protected]> wrote: > > On 2016-07-20 10:01, Michael Welzl wrote: > >>> On 20. jul. 2016, at 09.22, Anna Brunstrom <[email protected]> wrote: >>> >>> On 2016-07-19 17:59, Michael Welzl wrote: >>> >>>>> On 19. jul. 2016, at 17.52, Joe Touch <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On 7/19/2016 8:49 AM, 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. >>>>> 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! >>> The thing multi-streaming gives that I see could be useful for an >>> application is the ability to give different priorities to different >>> streams/flows. You could abstract that in different ways, but you need some >>> scope for what streams/flows you prioritize between that multi-streaming >>> gives you. >> I agree - but I haven’t yet stumbled over prioritization as a service to the >> application in one of the SCTP RFCs… probably it’s there somewhere. > > The ndata draft that I guess will be a RFC fairly soon has a priority > scheduler as part of it.
Ah! Cool, thanks for the pointer >> If it exists, wouldn’t the concept of prioritization within a definable >> group of flows be better to expose than multi-streaming as such? > > Yes, I agree that this would be a more general abstraction. We can make that happen in the minset draft :-) Very helpful, thank you! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
