Re: [rtcweb] realiable data service

[Randell Jesup <[e-mail]>]

On 7/18/2011 1:12 PM, Cullen Jennings wrote:
> On Jul 17, 2011, at 15:54 , Ted Hardie wrote:
>
>> On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings<[e-mail]>  wrote:
>>
>> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer.
>>
>> Can I see your dropbox incantation for remote camera movement?  I am particularly interested in how you make it useful without a reliable, near real-time message that says "go check dropbox for $foo"....
> Ok, Ok, - I deserver to made fun of.  There are something you can't do with drop box or XMPP but lets take the PTU control problem. I have seen protocols that have semantics like "start panning right" or "pan right 10 degrees relative to current position". These protocol all have an lousy user experience compared to the ones that have semantics of "go to absolutely position Y at time X". IMHO, the best way to do a real time PTU control protocol is just periodical send the absolute position you want the camera to be at and send it more than once, or each time the users presses the button, if you don't want to do an ACK. It's hard to been something like that if latency is important. If latency is not important, XMPP is easier. (thought I would still send absolute not relative). I'll note more than one system is doing PTU control over RTP using an approach much like sending DTMF via RTP.

I agree it's easier/more accurate to say "move to X".  However, people 
are used to various
"continuous" motion controls, like zoom and trying to frame a subject, 
or follow motion.  From
a UI point of view, a good low-delay continuous reactive system is often 
more functional, depending
the problem space.  People will find a way to fit their preferred user 
experience onto the protocol,
even if it's not a good fit for the protocol, because they don't care 
about the protocol - they
care about their UI.

>> To put this another way, a reliable protocol associated with a real time stream has some pretty obvious uses (gaming has also already been mentioned).
> I'm pushing back on it is obvious that there are use cases for this. That there is simultaneous need for the semantics of "you must deliver this data no matter how long it takes" and "this data need to get there in less than X time or it is useless" is not obvious to me.

It's rare that "no matter how long it takes" is hugely delayed - if it 
is, you have other, bigger
problems.  Delayed - could well be; usually only a little, with some 
jitter.  And SCTP would
be even better as far as that's concerned.

Talk to some RT networked game designers.  I'll bet they all use a mix 
of reliable and unreliable
protocols (perhaps not like TCP, more like SCTP).  But even though 
reliable == not guaranteed,
I'll bet they all want it to get there as fast as possible in the normal 
case.

People are ignoring the huge positive of having this data connection 
bundled with the other
streams and connected with them.  Having to set up a parallel reliable 
stream adds all sorts
of complexity to the application when firewall traversal/IP address 
changes/etc are included, and
then you have the issue of it being a second distinct stream from a 
congestion point of view - it
makes it very hard to control the relative bandwidth of the reliable 
stream versus all the unreliable
streams - you're likely to get ~ 50% for the reliable stream if you're 
overcommitted, with the % varying
quite a bit.  And if the stream has to go through a relay or server 
while media goes P2P
you have an issue for people designing services to use this protocol - 
increased cost and bandwidth
for one.  Even a chat-with-file-transfer - if the file xfer has to go 
through the server, you have to maintain
bandwidth for that case, and transfer speed may be limited by RTT of 
going through a remote server
(think Taiwan user to Taiwan user with a relay in the US).

All that said - yes, there are complexity issues to consider, which was 
why I was suggesting leveraging
an existing tunneled protocol like SCTP or even TCP-over-UDP.

-- 
Randell Jesup
[e-mail]