Re: [Taps] A proposal to throw out RTP

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.
> mariejo@mit.edu
> @SocialTVMIT
>
>> On Jun 4, 2015, at 9:37 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>> Well... it's a typical engineering trade-off decision to make...
>>
>>
>>> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <mariejo@mit.edu> 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
>>> marie@mjmontpetit.com
>>> mariejo@mit.edu
>>>
>>> On Jun 3, 2015, at 20:44, Christian Huitema <huitema@microsoft.com> 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.kuehlewind@tik.ee.ethz.ch
------------------------------------------