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