On 2016-07-19 17:59, Michael Welzl wrote:
On 19. jul. 2016, at 17.52, Joe Touch <to...@isi.edu> wrote:
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)
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
