Subject: [Taps] agenda topic: application - transport abstractions

From: Aaron Falk <[email-masked]>
Date: Wed, 4 Feb 2015 13:39:34 -0500

Thinking about how to make good use of our meeting in Dallas, I'd like to
propose we take some time to (re)visit the topic of how applications can
express what they want from transports by looking at a few examples and
maybe comparing them to what we are coming up with in the TAPS draft.

Given all the recent effort, RTCWeb seems like a timely topic and Michael
Tuexen has agreed to discuss the abstractions used in the API between the
javascript 'user' and the RTCWeb stack.  Marie-Jose Montpetite has offered
to talk about the needs of some future television applications (multisource
video/TV).

Sound interesting? Useful?  Have another application to talk about?

--aaron

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 4 Feb 2015 22:55:04 +0000

Well one reason I started being interested in TAPS was because of the video and of course the multisource version (video for example combining streaming, download, multimedia and social networking). For these use cases you need to be able to specify delay, loss (to avoid or minimize buffering events) adI could think in extreme cases even path (or multipath). So a way to abstract the services that could be summarized into “give me the best video now” would be very useful for all new video-based apps out there.

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Feb 4, 2015, at 1:39 PM, Aaron Falk <[email-masked]> wrote:
> 
> Thinking about how to make good use of our meeting in Dallas, I'd like to propose we take some time to (re)visit the topic of how applications can express what they want from transports by looking at a few examples and maybe comparing them to what we are coming up with in the TAPS draft.
> 
> Given all the recent effort, RTCWeb seems like a timely topic and Michael Tuexen has agreed to discuss the abstractions used in the API between the javascript 'user' and the RTCWeb stack.  Marie-Jose Montpetite has offered to talk about the needs of some future television applications (multisource video/TV).
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Feb 2015 15:24:14 -0800

On 2/4/2015 2:55 PM, Marie-Jose Montpetit wrote:
> Well one reason I started being interested in TAPS was because of the
> video and of course the multisource version (video for example combining
> streaming, download, multimedia and social networking). For these use
> cases you need to be able to specify delay, loss (to avoid or minimize
> buffering events)

For a streaming source, delay can be described (time offset, time offset 
variation). That is simple only for real-time streaming live, 
bidirectional content.

When you start including the size of the message - whether as a single 
bulk transfer, or the ability to buffer large amounts of it (for 
recorded content), then the size of the message is inherent in the 
notion of latency. You can't ask the network how long something will 
take if you don't tell it how big it is.

> I could think in extreme cases even path (or
> multipath).

I've said this before in MPTCP, but please don't confuse endpoint with 
path here. Same endpoints can mean different path, and using multiple 
endpoints is no guarantee of independent paths.

 > So a way to abstract the services that could be summarized
> into “give me the best video now” would be very useful for all new
> video-based apps out there.

What would "give me the best video now" mean to the transport layer?

Completely different things for Netflix, Vine, and Skype.

In summary, we need a better way to describe the services we want before 
we'll ever be able to expect the transport to handle them properly.

Joe

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 4 Feb 2015 23:29:42 +0000

> snip/snip

> In summary, we need a better way to describe the services we want before we'll ever be able to expect the transport to handle them properly.
> 
I totally agree.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Feb 2015 08:44:39 +0000

> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit <[email-masked]> wrote:
> 
>> snip/snip
> 

We've been around the "let's specify what the application wants, not what protocols can do" block a couple of times prior to creation of this group. We started and ended with the bottom-up'ish plan that is in the charter now.

So, if you take a look at item #2 in the charter, it's rather unclear what that item is going to look like, and in particular how we'll arrive there:

"2) Specify the subset of those Transport Services, as identified 
in item 1, that end systems supporting TAPS will provide, and 
give guidance on choosing among available mechanisms and 
protocols. Note that not all the capabilities of IETF Transport 
protocols need to be exposed as Transport Services."

We'll have to figure out reasonable ways to shorten the list in item #1 at some point; this could include compiling a number of services under more application-oriented terms - such as "willing to choose low latency at the cost of X". What this statement precisely means depends on "X", and I think we can get an idea of what "X" is when we create that service from the list in item #1, not out of the blue.

Does that make sense?

Cheers,
Michael

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 5 Feb 2015 08:54:46 +0000

> On Feb 5, 2015, at 3:44 AM, Michael Welzl <[email-masked]> wrote:
> 
> 

Yes but in fact I think that you have to look at both ends: define what the service wants can be tricky but necessary. On the other hand it also almost implies that the mechanims or services also expose their characteristics - if not, matching of services to transport cannot happen.
> We'll have to figure out reasonable ways to shorten the list in item #1 at some point; this could include compiling a number of services under more application-oriented terms - such as "willing to…
Yes but the issue will be in defining X - less latency at the expense of bandwidth or more complexity in the network or ??? Each of those may imply a different transport.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Feb 2015 09:57:35 +0000

> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> 
> 
> 

I couldn't parse this. What do you mean?

> Yes but the issue will be in defining X - less latency at the expense of bandwidth or more complexity in the network or ??? Each of those may imply a different transport. 

Agreed - my point is: when we build #1, X will come.

Michael

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 5 Feb 2015 11:21:47 +0000

What I mean is defining what the apps need is not independent of also defining what the protocols offer.

> On Feb 5, 2015, at 4:57 AM, Michael Welzl <[email-masked]> wrote:
> 
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Feb 2015 15:27:47 +0100

Then we agree.