Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Randell Jesup <[e-mail]>]

On 9/21/2011 7:45 AM, Hadriel Kaplan wrote:
> Just to make sure I'm on the same wavelength, you're talking about:
> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery.

I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for reliable
data delivery.  Similar arguments apply as for DCCP (solid specification), and
in addition the FreeBSD implementation apparently supports SCTP-over-UDP and is
very portable, so good working code is available to start.  SCTP also has other
benefits, like optional out-of-order delivery, and a datagram ('message') orientation.


> 2) Defining DDCP over UDP for message-oriented unreliable data delivery.
> 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the option for it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP)

This is certainly an option.  I'll note it means we'll run congestion control
on the data channels separately from media and from other data channels - this
is similar to how opening multiple TCP connections works.  I was hoping I could
find a way to include all the data channels in a single congestion-control framework
with the media channels, which would allow the application optional control over the
allocation of bits between media and data.  (I.e. a long-running file transfer could
starve the media channels eventually in bufferbloat situations.)

For DCCP (since it allows replacing the congestion-control algorithm) we may still
be able to meet my hopes for unreliable data; but reliable data is still a bit
out in the cold.

    Randell


> Correct?
>
> -hadriel
>
>
> On Sep 21, 2011, at 6:47 AM, Colin Perkins wrote:
>
>> On 21 Sep 2011, at 10:19, Harald Alvestrand wrote:
>>> On 09/20/2011 04:36 PM, Magnus Westerlund wrote:
>>>> On 2011-09-19 21:14, Harald Alvestrand wrote:
>>>>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote:
>>>>>> We need to standardize a number of Transport protocol functionalities for the RTCWEB data transport solution. To the degree that I do like to resurface some of my earlier suggestions around this. Why not use DCCP with TFRC or TCP like congestion control tunneled over UDP.
>>>>>>
>>>>>> The whole specification is ready. Which avoids any hiccup with the transport people and IESG.
>>>>> The last few times this has surfaced, the conversation has turned suddenly silent when I've asked where to find a DCCP-over-TFRC stack I can experiment with.... are there any out there that are "production ready"?
>>>> To my knowledge there is a DCCP stack in Linux. Exactly it status is unknown to me and which of the CC it supports. There has been also additional projects for implementations.
>>> I checked out the Linux stack, and concluded that it was:
>>> a) not supporting DCCP over UDP
>>> b) not possible to extract it and embed it in a browser
>>> The only project I could find for userspace DCCP was untouched for at least 3 years, and did not compile.
>> Agreed. The Linux DCCP code seems reasonably mature, but doesn't support the UDP encapsulation. The user-space DCCP-TP code is not in a good state to build upon.
>>
>>>> I would note that no implementation exist of DTLS with a CC algorithm and additional mechanism. Thus that would be a from scratch implementation effort without any input what has been done so far.
>>>>
>>>> And if we can in fact decide early on something fully specified you have a lot of time to implement this before the rest are standards ready.
>>> My worry is that without the ability to experiment, I have no way of verifying that the protocol satisfies the properties we are attributing to it.
>> This is a little pessimistic. The Linux DCCP code can certainly be used for lab-based experiments, and these can be made to give a reasonable idea of the performance of DCCP with the existing CCIDs. Not perfect, sure, but should be good enough to show whether the basic idea is worth exploring further.
>>
>> The main reason to consider DCCP-over-UDP isn't running code though, it's the solid specification. I'd argue that it will be easier to start with the DCCP spec, profile it down to what's needed by this group, plug in a new congestion control algorithm (CCID), and implement the result, than it would be to start both the specification and implementation efforts from scratch. As a congestion-controlled, connection-oriented, unreliable datagram service, there's not a lot in DCCP that we wouldn't want for RTCWeb (and those bits we might want to modify, such as the congestion control algorithm, are things where DCCP supports extensions).
>>
>>> Also, we *know* we'll be shipping products well ahead of the standards' final approval, with appropriate warnings that things *will* change between product versions. We don't have "a lot of time".
>>>>> The pseudoTCP stacks in libjingle have seen service for a long time....
>>>>>
>>>> Well, that is addressing another set of requirements namely the reliable data transport. Lets not confuse the two sets. We appear to have interest in both unreliable and reliable data transport.
>>> Yup, I pulled that in as an example of "code maturity".
>>>
>>>> Regarding pseudoTCP we still need a specification for it. I think for example the psuedo header used in the checksum needs specification in TCP over UDP. It might not be a big spec, but someone needs to write it and find a home for it. I would note that we are somewhat limited in this WG to actually do protocol work.
>>> It will have to seek approval elsewhere, if needed.
>>>
>>>

-- 
Randell Jesup
[e-mail]