Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Colin Perkins]

> On 20 Jul 2016, at 10:38, Michael Welzl  wrote:
> 
>> 
>> On 20. jul. 2016, at 10.27, Colin Perkins  wrote:
>> 
>>> On 19 Jul 2016, at 18:06, G Fairhurst  wrote:
>>> On 19/07/2016, 17:49, Michael Welzl wrote:
> On 19. jul. 2016, at 17.40, Joe Touch  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.

Surely you have a better API, with well-thought out hooks for tuning?

> 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).

Agree. I’m just reacting to “you’re suggesting to *not* expose these transport 
services too? I’d agree” which suggests something a little different.

-- 
Colin Perkins
https://csperkins.org/




___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Colin Perkins]

> On 19 Jul 2016, at 18:06, G Fairhurst  wrote:
> On 19/07/2016, 17:49, Michael Welzl wrote:
>>> On 19. jul. 2016, at 17.40, Joe Touch  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.

-- 
Colin Perkins
https://csperkins.org/




___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Anna Brunstrom]

On 2016-07-19 17:59, Michael Welzl wrote:


On 19. jul. 2016, at 17.52, Joe Touch  wrote:



On 7/19/2016 8:49 AM, Michael Welzl wrote:

On 19. jul. 2016, at 17.40, Joe Touch  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.


Cheers,
Anna



Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps



___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Mirja Kühlewind]

Sorry… s/multicast/multipath/  (stupid auto-correct)


> Am 19.07.2016 um 18:05 schrieb Mirja Kühlewind 
> :
> 
> 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 :
>> 
>> 
>> 
>> On 7/19/2016 8:49 AM, Michael Welzl wrote:
 On 19. jul. 2016, at 17.40, Joe Touch  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

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Mirja Kühlewind]

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 :
> 
> 
> 
> On 7/19/2016 8:49 AM, Michael Welzl wrote:
>>> On 19. jul. 2016, at 17.40, Joe Touch  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

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

[Michael Welzl]

> On 19. jul. 2016, at 17.40, Joe Touch  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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps