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