Re: [rtcweb] data-over-RTP vs data-over-datagram (Re: non-media data)

["Christian Hoene" <[e-mail]>]

> Returning to this thread after a few weeks.... I'm still being contrary
> to make sure we have all the issues explicit where they need to be...
> and I do hope that some of the people who actually want to send data
> (instead of us types who speculate about what you possibly might want)
> can speak up!

[Christian Hoene] Most RTP payload formats are for audio or video. I have not seen that RTP is just for other real time data such as GPS, location, orientation, input devices (mouse, kinect, etc...) or gaming data. Thus, I do not see that data over RTP is an option that is well supported. Real-time-Data-over-RTP seems not to be in the standardization traditions of AVT. Of course, this might change at some point in future.

Until then, I would suggest to support a plain real-time-data-over-datagram option, as we do not have to follow standards anyhow to support non-media data over whatsoever. 

Spoken up,
 Christian





> 
> On 04/15/11 16:28, Magnus Westerlund wrote:
> > Haralad and other interested
> >
> > Snipped out more parts as I added quite a lot around possible
> > alternatives for you to think about. See below
> >
> > Harald Alvestrand skrev 2011-04-15 15:12:
> >>> I promised to return to why I think TCP over RTP or more general,
> >>> generic data over RTP isn't the most suitable model.
> >>> - RTP is a protocol built towards real-time media. Yes the definition of
> >>> media can be pretty loose here. But carrying the individual datagrams of
> >>> a TCP connection over RTP is plainly stupid, when TCP over UDP will get
> >>> you all the desired functionality anyway with less overhead.
> >> RTP is, in the extreme view, a ~12-byte header and a  set of handling
> >> rules. We should look at what it is, not so much what it was originally
> >> thought to be designed for (a component in a framework for multicast
> >> distribution of unidirectional media channels).
> > Well, the handling rules include RTCP and an intention to handle a
> > number of different topologies with multi-party handling. There are also
> > additional signalling issues, like how to configure the RTCP bandwidth
> > value, which features to use and all these things. Things you may not
> > need for your data transport. If you need them, you anyway should define
> > an RTP payload format for your data format.
> If these questions have fixed answers in a specific scenario (like
> point-to-point), they can be handled by specifying a set of reasonable
> values for that scenario.
> > And to be frank, the transport and RAI ADs has been very hesitant to
> > allow any RTP payload format that is defined for just being a bit pipe
> > over RTP. The two reasons for this has been Application level framing
> > principle and the lack of congestion control for RTP.
> I do wonder about the ALF principle. In some ways, it seems reasonable
> under ALF that one should be able to use a framing mechanism that
> provides some of what we want without necessarily worrying that it
> provides more than what we want...
> 
> The congestion control is definitely an issue. With RTCWEB deployment
> likely to increase the amount of media streams encountering congestion
> significantly, I think we have to address this in a way that's
> applicable to RTP in general - but that's an AVTCORE matter, not an
> RTCWEB matter, I think.
> >>> - RTP requires RTP payload formats for anything it carries. That is to
> >>> ensure that the application level framing ideas are as well captured for
> >>> a particular media encoding as possible. That optimization is not
> >>> possible for general data.
> >> I think "general data" is a red herring. We can define a few different
> >> data-carrying "modes" that have different properties; if some of these
> >> are useful, I think it makes sense to define them.
> > I agree that different transport protocol provides different properties.
> > And that you should chose the one most appropriate. However, one
> usually
> > has to compromise on some aspects, either by needing to do specific
> > solution for ones data or accept some other potential limitation. On a
> > high level comparisons between our transport protocols I think can be
> > summarized like this:
> >
> > TCP: unicast only, congestion controlled reliable byte stream
> Also: Implemented in kernels, allowed through firewalls,
> double-NAT-traversal fails frequently.
> > SCTP: unicast, multihoming, congestion controlled, reliable and
> > unreliable, message oriented.
> Also: Not implemented in kernels, firewalls know nothing of it (unless
> UDP encapsulated). NAT boxes know nothing about it (so UDP encapsulation
> seems a must).
> > DCCP: unicast, unreliable, congestion controlled sequence numbered
> datagram
> The "also" list here is the same as for SCTP, I think.
> > RTP/UDP: unicast and multicast, unreliable, RTP payload of single MTU
> > size, medium time scale transport feedback.
> >
> > UDP: unicast and multicast, unreliable, datagram
> Properties of traversal of firewalls and NAT boxes are well known.
> Kernel implemented.
> >>> - If one can't do general optimization one goes with more general
> >>> transport solutions, thus why not use a more general data transport for
> >>> the general data?
> >> Pushing stuff towards a "more general data transport" requires one of
> >> two things:
> >> a) having an existing more general data transport that fulfils our
> >> requirements
> >> b) defining a new more general data transport that fulfils our
> requirements
> >> The second seems tough. The first ..... what's your preferred candidate?
> > Actually the one I think is easiest from a specification point of view
> > and that does provide a reasonable service for unreliable datagrams are:
> >
> > DTLS/DCCP/UDP
> >
> > That would be the following references:
> > https://datatracker.ietf.org/doc/rfc4340/ (Base Spec)
> > https://datatracker.ietf.org/doc/rfc4341/ (TCP-Like CC)
> > https://datatracker.ietf.org/doc/rfc4342/ (TFRC CC)
> > https://datatracker.ietf.org/doc/rfc5238/ (DTLS for DCCP)
> > https://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ (DCCP over
> UDP)
> >
> > My main concern is the maturity of available implementations of DCCP.
> > Otherwise it provides congestion control and can actually choose which
> > congestion control algorithms we want supported, TCP-like or TFRC. It
> > also have some additional features. One is that we get a second port
> > space providing additional multiplexing points.
> >
> > Please note that this is just a friendly suggestion. At least check it
> > out, and possible post some comments why it would be unsuitable.
> In a design point spectrum where Ian Hixie's 44-byte datagram header,
> this proposal and a "data-over-RTP" proposal are the 3 candidates, we
> should have enough design points that we can start discussing the
> criteria we evaluate them against (often a good thing).
> >>> - RTP and RTCP monitoring is also designed with more continous medias
> in
> >>> mind. Here we don't know how much such properties will be true. Also
> the
> >>> congestion controls available might actually have not the most suitable
> >>> properties for certain type of data.
> >> It's not clear to me that there *are* congestion controls available
> >> (other than media-specific ones).
> >> Which ones are you thinking of?
> > The one that is full defined is to run RTP over DCCP.
> > https://datatracker.ietf.org/doc/rfc5762/
> >
> > I guess the biggest issue is the lack of experience with this and
> > especially how you interface the DCCP stack to work well between media
> > encoding, RTP stack and the DCCP congestion control.
> If we buy DCCP anyway, this is certainly worth investigating.
> > The alternative, not standardized yet but closest available for RTP over
> > UDP is TFRC for RTP.
> > https://datatracker.ietf.org/doc/draft-gharai-avtcore-rtp-tfrc/
> >
> > That was in reasonable shape prior to its abandonment due to lack of
> > funding from the ones driving it.
> Does anyone want to pick it up and see what's missing?
> >
> >> Now, the flipside: What does RTP *have* that we will otherwise need
> >> to define? From your earlier list:
> >>
> >> - Congestion Controlled: eh... maybe not.
> >> - Confidentiality and  Integrity Protected - done, we've got SRTP.
> >> - Providing consent to receive data prior to allow transmission of
> >>    substantial amounts of data - done, we have ICE,
> >>    and need it for media too.
> >> - Some type of source authentication to prevent man in the middles
> >>     - done, we have SRTP
> >>
> >> So apart from congestion control, it seems that RTP's 12-byte header
> >> actually gives us a lot.
> > Well, the security parts can be provided by ICE and DTLS over UDP also.
> > we still are short the congestion control for such a thing plus all
> > these things that the UDP guidelines (RFC5405) discuss. Using RTP over
> > UDP does drag all the RTP baggage into something that may not needed it,
> > but it will provide some parts of what you need. If a particular data
> > format needs RTP functionality, it should define its own RTP payload
> > format anyway.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ----------------------------------------------------------------------
> > Ericsson AB                | Phone  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb