Hi, for multicast there is the simple example where one access network is more expensive to use than the other (in the sense where the user gets a bill at the end). In this case the user would potentially rather except a disconnect for a short time than sending data unnecessary over the expensive links (and the link should only be used if no other one is available).
Please go to the mptcp list and ask people there about their use cases because these (at least not all of these) people might not be subscribed to this list. Mirja > Am 19.07.2016 um 17:52 schrieb Joe Touch <to...@isi.edu>: > > > > 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) > > Joe _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
