Subject: [Taps] A proposal to throw out RTP

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Jun 2015 15:26:17 +0200

Hi,

I know this has been discussed before, but only briefly. I have two arguments that I'd like to bring forward towards removing RTP (/RTCP) from draft-ietf-taps-transports-04 and the documents that will follow it. I understand that it's a non-obvious question whether RTP should be considered a transport protocol or not, and I don't want to take a side in this or step on anyone's toes here - these are more practical, pragmatic considerations, and I'd just like to see how people react. If folks go crazy in response to this I won't keep arguing, but I'd be happy if I'd see some agreement:

Argument #1: RTP implementations need to be tied closer to the application than the implementation of transport such as TCP, DCCP, SCTP. There is usually a very tight interaction with the codec and RTP - a reaction to one specific incoming RTCP message, for instance. So I'd rather see a future TAPS system being *used* by RTP instead of *providing* RTP functionality.

Argument #2: TAPS has a non-negligible risk of ending up as an academic exercise. I understand that but I don't want that - I think we should do our best to keep TAPS "real". If that is our goal, including the world's largest protocol isn't perhaps ideal... I think it should be in our interest to try to keep the list in draft-ietf-taps-transports-04.txt reasonably contained.

Cheers,
Michael

---

From: [email-masked]
Date: Wed, 3 Jun 2015 15:48:27 +0100

> Hi,
>
> I know this has been discussed before, but only briefly. I have two
> arguments that I'd like to bring forward towards removing RTP (/RTCP) from
> draft-ietf-taps-transports-04 and the documents that will follow it. I
> understand that it's a non-obvious question whether RTP should be
> considered a transport protocol or not, and I don't want to take a side in
> this or step on anyone's toes here - these are more practical, pragmatic
> considerations, and I'd just like to see how people react. If folks go
> crazy in response to this I won't keep arguing, but I'd be happy if I'd
> see some agreement:
>
> Argument #1: RTP implementations need to be tied closer to the application
> than the implementation of transport such as TCP, DCCP, SCTP. There is
> usually a very tight interaction with the codec and RTP - a reaction to
> one specific incoming RTCP message, for instance. So I'd rather see a
> future TAPS system being *used* by RTP instead of *providing* RTP
> functionality.
>
I think the same.

> Argument #2: TAPS has a non-negligible risk of ending up as an academic
> exercise. I understand that but I don't want that - I think we should do
> our best to keep TAPS "real". If that is our goal, including the world's
> largest protocol isn't perhaps ideal... I think it should be in our
> interest to try to keep the list in draft-ietf-taps-transports-04.txt
> reasonably contained.
>
I'd prefer the document not to ignore RTP - but to say enough, so that
people can read further should this wish. If the above is correct, then I
think perhaps this document can cover this in the introduction, along with
a mention perhaps of other framing or content-oriented protocols that can
use transports.

> Michael
Gorry

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

---

From: Brian Trammell <[email-masked]>
Date: Wed, 3 Jun 2015 17:04:10 +0200

> On 03 Jun 2015, at 16:48, [email-masked] wrote:
> 
>> Hi,
>> 

+1

> a mention perhaps of other framing or content-oriented protocols that can

Agree as well. If we completely ignore RTP, it will be conspicuous in its absence.

I'd suggest a bit of tombstone text in the RTP section that explains the rationale behind not really digging into RTP for components/features... I can put together something (based more or less on this message) for the -05 rev I'm working on...

Cheers,

Brian

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 3 Jun 2015 11:10:53 -0400

+1
Don't ignore, but dont actively work on...
On 3 Jun 2015 11:04, "Brian Trammell" <[email-masked]> wrote:

> I'd suggest a bit of tombstone text in the RTP section that explains the
> rationale behind not really digging into RTP for components/features... I
> can put together something (based more or less on this message) for the -05
> rev I'm working on...
>
> Cheers,
>
> Brian
>
> >> Cheers,
> >> Michael
> >>
> > Gorry
> >

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 03 Jun 2015 17:58:11 +0200

Hi all,

>>> future TAPS system being *used* by RTP instead of *providing* RTP

Actually I think I don't agree here. Yes, it's tied closer to the application 
but I think for taps this is a (good) example where the interface is at a much 
higher level and therefore might have a value to discuss it. However... (see below)

> I'd suggest a bit of tombstone text in the RTP section that explains the rationale behind not really digging into RTP for components/features... I can put together something (based more or less on…

... I agree here. But I think (right now) I would still like to have an own RTP 
section but be very brief and give some reasoning why we don't wnant to go into 
further details. Just as a side remark, I don't see any reason to mention RTP in 
any following documents though.

Mirja

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: [email-masked]
------------------------------------------

---

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Jun 2015 18:48:04 +0200

i'm fine with all that...

Sent from my iPhone

> On 3. juni 2015, at 17:58, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> Actually I think I don't agree here. Yes, it's tied closer to the application but I think for taps this is a (good) example where the interface is at a much higher level and therefore might have a value to discuss it. However... (see below)
> 
>> 
>>> 
> ... I agree here. But I think (right now) I would still like to have an own RTP section but be very brief and give some reasoning why we don't wnant to go into further details. Just as a side remark, I don't see any reason to mention RTP in any following documents though.
> 
> Mirja
> 
> 
>> 
>> Cheers,
>> 
>> Brian
>> 
>>>> Cheers,
>>>> Michael
>>> Gorry
>>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 Jun 2015 18:44:09 +0000

> Actually I think I don't agree here. Yes, it's tied closer to the application but I
> think for taps this is a (good) example where the interface is at a much higher
> level and therefore might have a value to discuss it. However... (see below)

I don't quite agree either.

RTP is an extreme example of the split between "generic transport library" and "application specific transport implementation." There are quite a few RTP functions that are seldom found in other transports, but are worth considering:

1) The use of timestamps. This is quite fundamental for "real time" applications that need to synchronize the rendering of different media streams.

2) The tolerance for losses. This requires alignment of transmission units to "natural" media boundaries such as audio or video frames, or compression units within video frames.

3) The practice of FEC, including variable rate FEC. This is quite common in video transmission. A given frame will be transmitted as N data packets plus P redundancy packets, where N and P depend on size and importance of the frame, e.g. anchor frame versus delta.

-- Christian Huitema

---

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Jun 2015 22:07:52 +0200

Okay, I promised I won't insist, and I don't... still contributing to the tech debate here:

In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to be clear, I agree about mentioning RTP in the draft and I agree that it provides important functions! The question is whether RTP's functions should belong to the TAPS "service set" (which in fact is going to be defined in the group's second item, but this depends on the first...).

> On 3. jun. 2015, at 20.44, Christian Huitema <[email-masked]> wrote:
> 

Agreed - but that would make sense and work *over* pretty much every transport protocol, right?

> 2) The tolerance for losses. This requires alignment of transmission units to "natural" media boundaries such as audio or video frames, or compression units within video frames.

... which just means that RTP has to run over a transport that allows the application to control message boundaries.

> 3) The practice of FEC, including variable rate FEC. This is quite common in video transmission. A given frame will be transmitted as N data packets plus P redundancy packets, where N and P depend…

... which is indeed very closely tied to the application, and might not be the kind of thing you want to have in a generic layer, but you could implement it on top?

Cheers,
Michael

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Wed, 3 Jun 2015 23:26:32 +0200

I think that speaking specifically about any protocol in this document will
not be in the sens of an "abstract" interface for the Transport layer,
because abstraction means that application will no longer be aware of who
or what Transport services are really offered. But in the same time, this
abstract interface should cover all the protocols aspects, and so,
applications should not see a difference in the offered service, i.e. some
services (or functionalities) which are no longer available. I think that
this list of services is too short and must be extended to add more
services, especially those already offered, like data encryption for
example, or message-oriented transmission ...

On Wed, Jun 3, 2015 at 10:07 PM, Michael Welzl <[email-masked]> wrote:

> In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to
> be clear, I agree about mentioning RTP in the draft and I agree that it
> provides important functions! The question is whether RTP's functions
> should belong to the TAPS "service set" (which in fact is going to be
> defined in the group's second item, but this depends on the first...).
>
>
> > RTP is an extreme example of the split between "generic transport
> library" and "application specific transport implementation." There are
> quite a few RTP functions that are seldom found in other transports, but
> are worth considering:
> >
> > 1) The use of timestamps. This is quite fundamental for "real time"
> applications that need to synchronize the rendering of different media
> streams.
>
> > 2) The tolerance for losses. This requires alignment of transmission
> units to "natural" media boundaries such as audio or video frames, or
> compression units within video frames.
>
> ... which just means that RTP has to run over a transport that allows the
> application to control message boundaries.
>
>
> > 3) The practice of FEC, including variable rate FEC. This is quite
> common in video transmission. A given frame will be transmitted as N data
> packets plus P redundancy packets, where N and P depend on size and
> importance of the frame, e.g. anchor frame versus delta.
>
> ... which is indeed very closely tied to the application, and might not be
> the kind of thing you want to have in a generic layer, but you could
> implement it on top?
>
>
> Cheers,
> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 4 Jun 2015 00:11:10 +0200

nono. read the charter. it says that we’ll:

"1) Define a set of Transport Services, identifying the 
services provided by existing IETF protocols and congestion 
control mechanisms. As a starting point, the working group will 
consider services used 
between two endpoints.”

This is bottom-up, and let’s start this as small as … feasible.

Cheers,
Michael

> On 3. jun. 2015, at 23.26, Mohamed Oulmahdi <[email-masked]> wrote:
> 
> I think that speaking specifically about any protocol in this document will not be in the sens of an "abstract" interface for the Transport layer, because abstraction means that application will no longer be aware of who or what Transport services are really offered. But in the same time, this abstract interface should cover all the protocols aspects, and so, applications should not see a difference in the offered service, i.e. some services (or functionalities) which are no longer available. I think that this list of services is too short and must be extended to add more services, especially those already offered, like data encryption for example, or message-oriented transmission ... 
> 
> 
> On Wed, Jun 3, 2015 at 10:07 PM, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> > On 3. jun. 2015, at 20.44, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 4 Jun 2015 05:45:34 +0000

In my presentation in Dallas I had suggested adding RTP (and even HTTP) because as both Mirja and Christian mention some 'applications' are requesting functionalities that are got given elsewhere.

Marie-José Montpetit
[email-masked]
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Thu, 4 Jun 2015 09:37:13 +0200

Well... it's a typical engineering trade-off decision to make...

> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <[email-masked]> wrote:
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 4 Jun 2015 10:32:32 +0200

Sounds to me like we know we want to cover some of the unique features/components of RTP without having to go to the trouble of wedging a full description of the protocol (as in the other section) into the doc, a task complicated by the fact that RTP assumes a more fluid separation of responsibility among itself, its undertransport(s), and its specific application than is the case with other protocols.

So I would suggest the following: we have an abbreviated RTP section in this document that (1) points out this difference as potentially architecturally interesting (which itself might be input to the third charter item) and (2) enumerates only those features which are unique to RTP among protocols treated in the document.

(Varun, as current pen-holder on the RTP section, does this make sense to you?)

Cheers,

Brian

Sent from my iPhone

> On 04 Jun 2015, at 09:37, Michael Welzl <[email-masked]> wrote:
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 4 Jun 2015 09:51:00 +0000

From the discussion in Dallas I think we may also need to define what an “application” is…

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

> On Jun 4, 2015, at 9:37 AM, Michael Welzl <[email-masked]> wrote:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 04 Jun 2015 12:34:28 +0200

It's in the doc:

"Application:  an entity that uses the transport layer for end-to-end
       delivery data across the network (this may also be an upper layer
       protocol or tunnel encapsulation)."

Mirja

Room ETZ G93
phone: +41 44 63 26932

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 12:11:16 -0700

>       protocol or tunnel encapsulation)."

"End to end" is *defined* as the endpoints of the transport association.

So, basically:

"Application:  an entity that uses the transport layer for delivery of
data between the transport endpoints."

However, *every* protocol is trivially defined as:

	A mechanism between two or more parties to exchange data
	(information) between those parties.

I.e., as a result, an app is defined EXACTLY and ONLY by the following:

	Application: an entity that *uses* a transport layer.

Every other part of the definition is irrelevant, IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 14:12:21 -0700

On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> I think that speaking specifically about any protocol in this document
> will not be in the sens of an "abstract" interface for the Transport
> layer, because abstraction means that application will no longer be
> aware of who or what Transport services are really offered.

We need to be more clear in what we are discussing.

E.g., an "abstract API" (as I've been calling it) is described as in RFC
793:

	OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS

That's abstract only in the sense that it does NOT specify an
implementation in Linux, for example. It is not so abstract that it
applies to all transports - it's indicated for TCP only.

What you're proposing is a "universal interface", whether abstract
(described as above, using words to describe app-level actions and
events) or instantiated (e.g., using Unix socket(), connect(), accept(),
listen(), etc.).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 14:20:37 -0700

On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
> In my presentation in Dallas I had suggested adding RTP (and even
> HTTP) because as both Mirja and Christian mention some 'applications'
> are requesting functionalities that are got given elsewhere.

The core of this issue is "what is a transport protocol".

To the user, "transport" is the entire stack between their program and
the network (IP) layer - sometimes even including that (e.g., IPsec).

To typical transport protocols (e.g., UDP, TCP), everything that
accesses a transport protocol is the "application" layer.

>From the document:
   Transport Service:  a set of transport service features, without an
      association to any given framing protocol, which provides a
      complete service to an application.

   Transport Protocol:  an implementation that provides one or more
      different transport services using a specific framing and header
      format on the wire.

By those definitions, EVERYTHING between the user program and the link
layer is arguably part of the services an app sees, which include "shim"
services and layers such as: IPsec, TLS, and RTP.

I would argue that HTTP is the application that uses TCP (or TLS/TCP),
but not a separate service, but that's true only for conventional web
service.

There are many services built on top of HTTP, at which point HTTP is
just another part of what this document calls a "transport service".

As a result, unless you'll be describing every possible stack between
the user program and the link layer, this document cannot proceed with
the current definitions.

Joe

---

From: Helge Backhaus <[email-masked]>
Date: Fri, 05 Jun 2015 14:11:27 +0200

Am 04.06.2015 um 23:20 schrieb Joe Touch:
>> In my presentation in Dallas I had suggested adding RTP (and even HTTP)
>> because as both Mirja and Christian mention some 'applications' are
>> requesting functionalities that are got given elsewhere.
>
> To the user, "transport" is the entire stack between their program and the
> network (IP) layer - sometimes even including that (e.g., IPsec).
>
> To typical transport protocols (e.g., UDP, TCP), everything that accesses a
> transport protocol is the "application" layer.
>
>> From the document:
> association to any given framing protocol, which provides a complete service
> to an application.
>
> Transport Protocol:  an implementation that provides one or more different
> transport services using a specific framing and header format on the wire.
>
> By those definitions, EVERYTHING between the user program and the link layer
> is arguably part of the services an app sees, which include "shim" services
> and layers such as: IPsec, TLS, and RTP.
>
> I would argue that HTTP is the application that uses TCP (or TLS/TCP), but
> not a separate service, but that's true only for conventional web service.
>
> There are many services built on top of HTTP, at which point HTTP is just
> another part of what this document calls a "transport service".
>
> As a result, unless you'll be describing every possible stack between the
> user program and the link layer,

Shouldn't this ideally be the (long-term) goal of TAPS?

Of course it will never be feasible to consider every conceivable existing or 
future stack in practice. Thankfully, since it has been stated multiple times 
that TAPS is not intended to replace everything that exists out there, it's 
maybe good enough to have a look at some stacks...?

> this document cannot proceed with the current definitions.

So could a possible way forward be to leave the definitions as they are and add 
a description of the considered stack(s) to the document? For now "just" TCP, 
UDP, SCTP, ... over IPv4/6 etc.

At a later point that could be updated to services provided by the same stack 
with RTP and the likes on top and a third with HTTP over TCP(/TLS) ... the goal 
being to at least cover the "popular" stack (combinations) at some point.

Wouldn't that help to simplify the discussion which protocols are in and out of 
scope as service providers at a given point in time a lot?

> Joe

Apologies for just barging in like that. Im a long-time TAPS lurker so to speak 
and genuinely interested in opinions regarding such an approach.

Helge

-- 
Karlsruhe Institute of Technology (KIT)
Institut für Telematik

Dipl.-Inform. Helge Backhaus
research assistant

Zirkel 2
Building 20.20
Room 352

D-76128 Karlsruhe

phone: +49 721 608 46402

[email-masked]
www.tm.kit.edu
KIT – Universität des Landes Baden-Württemberg und
nationales Großforschungszentrum in der Helmholtz-Gemeinschaft

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2015 09:49:36 -0700

> Am 04.06.2015 um 23:20 schrieb Joe Touch:
...
> Shouldn't this ideally be the (long-term) goal of TAPS?

This would require an exponential number of service descriptions.

IMO, it's better to describe them as a linear number of composable
components and declare the composition rules.

(that's not novel; that's what we do throughout the IETF)

> So could a possible way forward be to leave the definitions as they are
> and add a description of the considered stack(s) to the document? For
> now "just" TCP, UDP, SCTP, ... over IPv4/6 etc.

If you ignore the deficiency of the definitions, then it's impossible to
move together on the remainder of the doc.

Joe

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Fri, 5 Jun 2015 21:53:00 +0200

> applies to all transports - it's indicated for TCP only.

This definition of 'abstract interface" is specific for a given protocol,
but the aim in TAPS is a higher level (services). In other words, if this
is the définition of an abstract interface, and is already defined in RFC
793, what will be the contribution of TAPS by defining its abstract
interface?

The objective of TAPS is to change the traditional way to use the Transport
layer. In fact, traditionally, applications select the appropriate
transport service by selecting a given transport protocol. The TAPS vision
is to change this, so as applications will request only their desired
services, via this abstract interface, and it is to the Transport layer to
choose the appropriate protocol according to the application request. It is
this level of abstraction that is aimed by TAPS. (see the charter, point 3
especially)

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2015 13:21:32 -0700

On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> 
> 
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> This definition of 'abstract interface" is specific for a given
> protocol, but the aim in TAPS is a higher level (services). In other
> words, if this is the définition of an abstract interface, and is
> already defined in RFC 793, what will be the contribution of TAPS by
> defining its abstract interface?

The first step towards a universal abstract interface is to understand
the current specific abstract interfaces. That's what the current
document is focused on.

> The objective of TAPS is to change the traditional way to use the
> Transport layer. In fact, traditionally, applications select the
> appropriate transport service by selecting a given transport protocol.
> The TAPS vision is to change this, so as applications will request only
> their desired services, via this abstract interface, and it is to the
> Transport layer to choose the appropriate protocol according to the
> application request. It is this level of abstraction that is aimed by
> TAPS. (see the charter, point 3 especially)

In order to unify or further abstract the API, the current API needs to
be understood - but the discussion on the list indicates a lot of
disagreement on this.

Joe

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Fri, 5 Jun 2015 22:37:33 +0200

I agree, the discussion should be better  structured ...

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 8 Jun 2015 10:19:52 +0200

Hi Joe,

the document defines one more term:

Transport Service Instance:  an arrangement of transport protocols
      with a selected set of features and configuration parameters that
      implements a single transport service, e.g. a protocol stack (RTP
      over UDP).

This is to describe also a stack of protocols which an application might use to get a certain transport service. (we might need to re-write this maybe, because I now have the feeling that this is hard to understand).

Currently we are not using this term in this document because we try to describe components of anything that might/could provide a transport service feature of all protocols that that might be part of a protocol stack that can be accessed by an application.

That’s what we had in mind when we came up with this terminology and I think think it covers the case where HTTP over TCP is used as a transport ‚substitute‘.

Mirja

> Am 04.06.2015 um 23:20 schrieb Joe Touch <[email-masked]>:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Jun 2015 21:10:03 -0700

On 6/8/2015 1:19 AM, Mirja Kühlewind wrote:
> This is to describe also a stack of protocols which an application
> might use to get a certain transport service. (we might need to re-write
> this maybe, because I now have the feeling that this is hard to understand).

If that's what it means, it certainly needs to be rewritten. A substack
of protocols isn't "an arrangement of transport protocols". The former
is vertical and involves functional composition; the latter is
horizontal ("peers" in the ISO stack at L4) and involves the union of
capabilities of the peers.

> Currently we are not using this term in this document because we try
> to describe components of anything that might/could provide a transport
> service feature of all protocols that that might be part of a protocol
> stack that can be accessed by an application.

I don't understand that either.

I really think that the definitions need to decouple the concept of
service interface to the upper layer from mechanisms that provide those
services.

> That’s what we had in mind when we came up with this terminology and
> I think think it covers the case where HTTP over TCP is used as a
> transport ‚substitute‘.

HTTP isn't a transport protocol. I don't know anyone who would call it
that or be able to use it as a substitute for TCP.

Joe