Adam, Thanks for sharing your thoughts and advice. I'm not sure that you read the whole post, though. Regarding TCP as a "last resort" I have to disagree. Consider YouTube live -- they use TCP for ingress and egress, and for good reason. That is exactly the type of scenario that I was discussing. Not a google hangout. When broadcasting to a large audience, 1 sec latency is nothing, and packets are not "dropped on the floor."
On Thu, Dec 12, 2013 at 7:51 PM, Adam Roach <[email protected]> wrote: > On 12/12/13 17:09, [email protected] wrote: > > NACK exists for video packets, but audio is a different story, and some > people's connections have high loss. > > > For connections with high loss, you'll want to keep in mind that TCP is > likely to make life for your users worse, not better. > > The problem is that you're going to end up with TCP head-of-line blocking. > If you lose a single packet and wait for a TCP retransmit, that's possibly > okay, depending on what your TCP parameters have converged to. Once you get > into high loss situations and lose two consecutive packets, you've pretty > much blown any "real-time-ness" of your TCP connection. > > At best, a sophisticated implementation might play packets out slightly > faster than real-time, hopefully with appropriate frequency adjustments. > More realistically, you'll probably have implementations either become > permanently behind by 500ms, 1000ms, or more; or drop received packets on > the floor to catch up. A delay on that order makes the connection unusable > for conversation, and I can't imagine forcing the receiver to drop packets > is in any way preferable to letting the network lose them instead. > > So, yeah, there's a really good reason real-time communications are done > over UDP whenever possible. TCP should be a last resort. > > I guess the overarching issue here is that ICE-TCP provides what I > consider to be an imperceptibly small improvement over TURN-TCP. But, as > Eric says, if you want to give us patches, we're not opposed to ICE-TCP on > principle -- it's just that the return on investment is so very, very small. > > One final thought: If you're absolutely determined to use TCP for your > audio, even after carefully considering the factors above, you can set up > your conference server to act as a TURN-TCP server (just speak the TURN > over TCP protocol, with RTP encapsulated inside it, but process and > generate the RTP locally), and configure your PeerConnections to use it as > their sole ICE server. > > -- > Adam Roach > Principal Platform Engineer > [email protected] > +1 650 903 0800 x863 > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
