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

[Magnus Westerlund <[e-mail]>]

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.

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.

>> - 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

SCTP: unicast, multihoming, congestion controlled, reliable and
unreliable, message oriented.

DCCP: unicast, unreliable, congestion controlled sequence numbered datagram

RTP/UDP: unicast and multicast, unreliable, RTP payload of single MTU
size, medium time scale transport feedback.

UDP: unicast and multicast, unreliable, datagram

>> - 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.

>> - 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.

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.


> 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]
----------------------------------------------------------------------