Re: [rtcweb] realiable data service

[Randell Jesup <[e-mail]>]

On 7/18/2011 9:56 AM, Magnus Westerlund wrote:
> On 2011-07-15 19:29, Tim Panton wrote:
>> I don't think it is very hard to implement, we could take RFC 5456's
>> sequencing and retry mechanism for example. or indeed Plan9's IL .
> I would warn about thinking this is easy. It is easy to get something
> that works on sunny days, it is hard to build something that is secure,
> efficient, robust and fair.

Agreed, absolutely - which is why I don't want 100 bad designs (let 
alone implementations)
in Javascript.


> I would like to point out that a reliable protocol do need a number of
> functions. If those are achieve from a lower layer or need to be
> implemented in this protocol is a choice. However, functionalities such as:
>
> - Congestion Control
> - Flow Control
> - Retransmission
> - RTT estimation
> - Buffer handling
> - Parameter and functionality negotiation
>
> Are likely all need for a safe and stable and future safe protocol.
>
> There are good reasons for choosing something there is experience in
> that it works.

Agreed also.  There are a few options, one of this is:
1) Encapsulated TCP-over-UDP, where the UDP channel is set up by the same
     mechanisms we use to set up the RTP channels, such as 
http://code.google.com/p/udptunnel/
     This is a big advantage in that normally devices behind NATs can't 
easily set up a direct TCP
     connection, and we can leverage the ability to set up p2p UDP 
channels to get it.

     The UDP channel could participate in the proposed shared bandwidth 
handling/
     congestion control, which is an advantage over a separate TCP 
channel.  The downside is that
     TCP's AIMD may cause interactions with the underlying bandwidth 
handling, so it may need
     to be excluded - some analysis is needed, once we know what we're 
doing on congestion
     control for the UDP channels.

     TCP's time characteristics are very well understood, though not 
optimal.

     The MTU would be slightly reduced - shouldn't be a problem.

It's not a datagram service, which is a minor downside, which offers the 
second option:
2) SCTP-over-UDP.  This is datagram-oriented and provides reliable delivery.
      It supports ECN and congestion control.

      One nice thing is that SCTP allows for unreliable delivery but 
with sequencing, or reliable
      delivery without in-sequence delivery, dependent on the 
application needs.  This can help
      the application optimize the realtime aspects of the reliable channel.

-- 
Randell Jesup
[e-mail]