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

[Harald Alvestrand <[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!

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