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

From: Michael Welzl <[email-masked]>
Date: Mon, 18 Jul 2016 09:22:51 +0200

Hi,

draft-gjessing-taps-minset-02 suggests that all transport service 
features related to multi-streaming and usage of multiple paths are 
“automatable”. The rationale is given in Section 4: 
https://tools.ietf.org/html/draft-gjessing-taps-minset-02#section-4
(this particular section says “removed” which is a mistake, to be fixed 
in the next update; sorry! - read as “classified as automatable”)

Note that abstraction always comes with loss of some control, that’s 
inevitable. It has to hurt a little bit  :-)
- our thinking is that none of these transport service features require 
application-specific knowledge and hence shouldn’t be exposed.

Thoughts?

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Tue, 19 Jul 2016 07:49:38 +0000

Hi Michael-

It seems to me that one could answer the question separately whether the
upper layer should be able to control the use of multi-streaming or
multi-paths vs. know whether multi-streaming or multi-paths are in use.  I
would think that there no reason to hide this information from apps.  would
you agree?

--aaron

On Mon, Jul 18, 2016 at 9:22 AM Michael Welzl <[email-masked]> wrote:

> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>
-- 
--aaron

=====Short message from my phone=====

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 19 Jul 2016 13:02:50 +0200

Hi Michael, hi all,

I believe there is actually quite a bit of discussion currently in MPTCP about how important it probably is to have an interface to the application and get input about upper layer preferences. Maybe ask on the mptcp list for input?

Mirja

> Am 19.07.2016 um 09:49 schrieb Aaron Falk <[email-masked]>:
> 
> Hi Michael-
> 
> It seems to me that one could answer the question separately whether the upper layer should be able to control the use of multi-streaming or multi-paths vs. know whether multi-streaming or multi-paths are in use.  I would think that there no reason to hide this information from apps.  would you agree?
> 
> --aaron
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jul 2016 14:27:16 +0200

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.

Cheers,
Michael

> On 19. jul. 2016, at 13.02, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael, hi all,
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jul 2016 08:40:51 -0700

> 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 s…

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.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jul 2016 17:49:49 +0200

> On 19. jul. 2016, at 17.40, Joe Touch <[email-masked]> wrote:
> 
> 
> 

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jul 2016 08:52:59 -0700

> 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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jul 2016 17:59:01 +0200

> On 19. jul. 2016, at 17.52, Joe Touch <[email-masked]> wrote:
> 
> 
> 

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!

Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 19 Jul 2016 18:05:11 +0200

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-masked]>:
> 
> 
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 19 Jul 2016 18:05:54 +0200

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

> Am 19.07.2016 um 18:05 schrieb Mirja Kühlewind <[email-masked]>:
> 
> Hi,
>

---

From: G Fairhurst <[email-masked]>
Date: Tue, 19 Jul 2016 18:06:26 +0200

On 19/07/2016, 17:49, Michael Welzl wrote:
>> On 19. jul. 2016, at 17.40, Joe Touch<[email-masked]>  wrote:
>>
>>
>>
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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jul 2016 18:12:07 +0200

will do (list). about your example: on my phone it's the os deciding, not the app...   which is my point   :)

Sent from my iPhone

> On 19. jul. 2016, at 18.05, Mirja Kühlewind <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jul 2016 10:38:15 -0700

> 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 potentia…

That's a great example - expense is the application criteria. That
criteria is enough for the net to make a decision without needing the
app to be involved.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Tue, 19 Jul 2016 23:08:09 +0200

> On 19. jul. 2016, at 18.06, G Fairhurst <[email-masked]> wrote:
> 
> 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.

Sounds like you’re suggesting to *not* expose these transport services too?

I’d agree.

We can’t make a “perfect” decision here, it’s a trade-off: this is the part of TAPS where we can’t work with simple rules anymore but we have to make some deliberate design choices.

Cheers,
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Wed, 20 Jul 2016 09:22:13 +0200

> 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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Jul 2016 10:01:56 +0200

> On 20. jul. 2016, at 09.22, Anna Brunstrom <[email-masked]> wrote:
> 
> 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.

I agree - but I haven’t yet stumbled over prioritization as a service to the application in one of the SCTP RFCs… probably it’s there somewhere.
If it exists, wouldn’t the concept of prioritization within a definable group of flows be better to expose than multi-streaming as such?

(e.g. this could just as well be mapped down to methods that couple the congestion control of multiple connections instead of real multi-streaming)
 
Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 10:27:21 +0200

> On 19 Jul 2016, at 18:06, G Fairhurst <[email-masked]> wrote:

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/

---

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Jul 2016 10:38:30 +0200

> On 20. jul. 2016, at 10.27, Colin Perkins <[email-masked]> wrote:
> 

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.

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

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 10:42:39 +0200

> On 20 Jul 2016, at 10:38, Michael Welzl <[email-masked]> wrote:
> 
>> 

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

> 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/

---

From: Michael Welzl <[email-masked]>
Date: Wed, 20 Jul 2016 10:44:56 +0200

> On 20. jul. 2016, at 10.42, Colin Perkins <[email-masked]> wrote:
> 
> 

A good TAPS implementation should!
For now, with our “minset” draft, TAPS is only identifying which things could be “hidden” (automatized).

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

Ah. Ok - have to be careful with language… “not expose” is stricter than what I meant.

Cheers,
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 22 Jul 2016 10:27:55 +0200

> I agree - but I haven’t yet stumbled over prioritization as a service to the application in one of the SCTP RFCs… probably it’s there somewhere.

The ndata draft that I guess will be a RFC fairly soon has a priority 
scheduler as part of it.

> If it exists, wouldn’t the concept of prioritization within a definable group of flows be better to expose than multi-streaming as such?

Yes, I agree that this would be a more general abstraction.

Cheers,
Anna

---

From: Michael Welzl <[email-masked]>
Date: Fri, 22 Jul 2016 10:30:18 +0200

> On 22. jul. 2016, at 10.27, Anna Brunstrom <[email-masked]> wrote:
> 
> The ndata draft that I guess will be a RFC fairly soon has a priority scheduler as part of it.

Ah! Cool, thanks for the pointer

> Yes, I agree that this would be a more general abstraction.

We can make that happen in the minset draft  :-)

Very helpful, thank you!

Cheers,
Michael