Re: [rtcweb] realiable data service

[Randell Jesup <[e-mail]>]

On 7/15/2011 1:29 PM, Tim Panton wrote:
> If we don't specify a  reliable transport then all the page authors will end adding a reliable layer in javascript, it will be as ugly as DTMF in RTP !
> Or worse it will be spray and pray.
>
> Most of the use-cases I can think of need  sequenced and reliable datagrams. If I'm playing a game I don't want it to
> drop or mis-order any one of the actions in the unholster, point, shoot  sequence :-)

I must agree that if we don't provide a reliable transport in 
conjunction with the
other streams, you'll get a hodgepodge of incompatible, semi-functional
reliable transports layered on top of unreliable streams.  Not that one 
can't do a good
reliable transport on top of an unreliable layer, but people have 
varying abilities
to get it right.    Also, an integrated solution might have options for 
better
performance than a user-layered solution would (for example, prioritizing
certain packets from a reliable stream like restransmits or acks).

As for the need - one of the first real-time apps on the internet was 
netrek.  This
predates the  web by years (I was in a netrek league in 1991), in the 
days when
a big international company would have a 64Kbps connection.  The 
original TCP-based
protocol broke down badly when exposed to congestion and the real net.  
The solution
was to break the data streams into two: one unreliable one for most 
positional updates,
and a reliable stream for game-state-critical data (like "you're dead").

Saying "if you want reliable data, use a proxy" is also silly IMHO.

Perhaps some here from or formerly from Adobe can speak to the utility 
of reliable streams
in RTFMP.

In VoIP there's a consistent issue with the need to do some things (like 
DTMF) reliably when
your primary streams are unreliable.  Witness DTMF and the mess over RFC 
2833 vs SIP INFO.

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

-- 
Randell Jesup
[e-mail]