Sorry… s/multicast/multipath/ (stupid auto-correct)
> Am 19.07.2016 um 18:05 schrieb Mirja Kühlewind > <[email protected]>: > > 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 <[email protected]>: >> >> >> >> 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) >> >> Joe > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
