On 19/07/2016, 17:49, 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.

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.

Gorry

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to