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 protected]> 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 <[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. > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
