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.
[email protected]
@SocialTVMIT
On Jun 4, 2015, at 9:37 AM, Michael Welzl <[email protected]> wrote:
Well... it's a typical engineering trade-off decision to make...
On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <[email protected]> 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
[email protected]
[email protected]
On Jun 3, 2015, at 20:44, Christian Huitema <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
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: [email protected]
------------------------------------------
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
