[Taps] A proposal to throw out RTP

[Michael Welzl]

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[gorry]

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

> Cheers,
> Michael
>
Gorry

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

Re: [Taps] A proposal to throw out RTP

[Brian Trammell]

> On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk wrote:
> 
>> 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.

+1

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

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

>> Cheers,
>> Michael
>> 
> Gorry
> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Jon Crowcroft]

+1
Don't ignore, but dont actively work on...
On 3 Jun 2015 11:04, "Brian Trammell"  wrote:

>
> > On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk wrote:
> >
> >> 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.
>
> +1
>
> >
> >> 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.
>
> 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
>
> >> Cheers,
> >> Michael
> >>
> > Gorry
> >
> >> ___
> >> 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
>
>
> ___
> 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

Re: [Taps] A proposal to throw out RTP

[Mirja Kühlewind]

Hi all,

On 03.06.2015 17:04, Brian Trammell wrote:



On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk wrote:


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.


+1


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)







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.


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


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


___
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




___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps



--
--
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: mirja.kuehlew...@tik.ee.ethz.ch
--

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

i'm fine with all that...

Sent from my iPhone

> On 3. juni 2015, at 17:58, Mirja Kühlewind  
> wrote:
> 
> Hi all,
> 
>> On 03.06.2015 17:04, Brian Trammell wrote:
>> 
 On 03 Jun 2015, at 16:48, go...@erg.abdn.ac.uk wrote:
 
 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.
>> 
>> +1
> 
> 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)
> 
>> 
>>> 
 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.
>> 
>> 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...
> 
> ... 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
>>> 
 ___
 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
>> 
>> 
>> 
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> -- 
> --
> 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: mirja.kuehlew...@tik.ee.ethz.ch
> --
> 
> ___
> 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

Re: [Taps] A proposal to throw out RTP

[Christian Huitema]

> 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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

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

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Mohamed Oulmahdi]

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  wrote:

> 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 
> wrote:
> >
> >> 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.
>
> 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 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
>
> ___
> 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

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

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  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  > wrote:
> 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  > > wrote:
> >
> >> 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.
> 
> 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 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
> 
> ___
> 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

Re: [Taps] A proposal to throw out RTP

[Marie-Jose Montpetit]

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
ma...@mjmontpetit.com
mari...@mit.edu

On Jun 3, 2015, at 20:44, Christian Huitema  wrote:

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

Re: [Taps] A proposal to throw out RTP

[Michael Welzl]

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


> On 04 Jun 2015, at 07:45, 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.
> 
> Marie-José Montpetit
> ma...@mjmontpetit.com
> mari...@mit.edu
> 
> On Jun 3, 2015, at 20:44, Christian Huitema  wrote:
> 
>>> 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
>> 
>> ___
>> 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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Brian Trammell]

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  wrote:
> 
> Well... it's a typical engineering trade-off decision to make...
> 
> 
>> On 04 Jun 2015, at 07:45, 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.
>> 
>> Marie-José Montpetit
>> ma...@mjmontpetit.com
>> mari...@mit.edu
>> 
>> On Jun 3, 2015, at 20:44, Christian Huitema  wrote:
>> 
 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
>>> 
>>> ___
>>> 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
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Marie-Jose Montpetit]

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


Marie-Jose Montpetit, Ph.D.
mari...@mit.edu
@SocialTVMIT

> On Jun 4, 2015, at 9:37 AM, Michael Welzl  wrote:
> 
> Well... it's a typical engineering trade-off decision to make...
> 
> 
>> On 04 Jun 2015, at 07:45, 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.
>> 
>> Marie-José Montpetit
>> ma...@mjmontpetit.com
>> mari...@mit.edu
>> 
>> On Jun 3, 2015, at 20:44, Christian Huitema  wrote:
>> 
 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
>>> 
>>> ___
>>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Mirja Kühlewind]

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

On 04.06.2015 11:51, Marie-Jose Montpetit wrote:

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


Marie-Jose Montpetit, Ph.D.
mari...@mit.edu
@SocialTVMIT


On Jun 4, 2015, at 9:37 AM, Michael Welzl  wrote:

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



On 04 Jun 2015, at 07:45, 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.

Marie-José Montpetit
ma...@mjmontpetit.com
mari...@mit.edu

On Jun 3, 2015, at 20:44, Christian Huitema  wrote:


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

___
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






--
--
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: mirja.kuehlew...@tik.ee.ethz.ch
--

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/4/2015 3:34 AM, Mirja Kühlewind wrote:
> 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)."

"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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Helge Backhaus]

Am 04.06.2015 um 23:20 schrieb Joe Touch:



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,


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

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


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 5:11 AM, Helge Backhaus wrote:
> Am 04.06.2015 um 23:20 schrieb Joe Touch:
...
>> 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?

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)

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

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

Joe

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Mohamed Oulmahdi]

On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  wrote:

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

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)

>
> 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
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> 
> 
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  > wrote:
> 
> 
> 
> 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.
> 
> 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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Mohamed Oulmahdi]

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

On Fri, Jun 5, 2015 at 10:21 PM, Joe Touch  wrote:

>
>
> On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> >
> >
> > On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  > > wrote:
> >
> >
> >
> > 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.
> >
> > 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
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Mirja Kühlewind]

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/8/2015 1:19 AM, Mirja Kühlewind wrote:
> 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).

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

> Mirja
> 
> 
> 
>> Am 04.06.2015 um 23:20 schrieb Joe Touch :
>>
>>
>>
>> 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
> 

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps