[Live-devel] Unable to play RTP over TCP when RTT is large

Arslan, Engin engin at illinois.edu
Sat Jan 14 15:08:52 PST 2017


Hi Ross,

Thanks for the reply. I checked the link and agree that TCP performance can be affected badly when rtt is high and buffer size is small or loss rate is high. However, I set the  buffer sizes to high enough values as:

sudo sysctl -w net.core.wmem_max=16777216
sudo sysctl -w net.ipv4.tcp_wmem='4096 16384 16777216'
sudo sysctl -w net.core.rmem_max=25165824
sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 25165824’

Since I'm testing on local network with ethernet connection, loss rate should not be problem for TCP performance. I can actually get 100 Mbps throughput when using TCP with iperf or simple client-server communication when RTT is 100ms. So I guess it is not that TCP cannot obtain enough throughput. I’m certainly not claim this issue is specific to openRTSP. I’m just trying to understand the behavior and possible ways to alleviate. I am guessing some rtsp streaming specific reason(s) hold TCP back from reaching full speed but not sure what and why. Any ideas/suggestions appreciated.

Thanks
Engin 

> On Jan 14, 2017, at 3:49 PM, Ross Finlayson <finlayson at live555.com> wrote:
> 
> This has nothing to do with our software; it’s an inevitable property of TCP connections.
> 
> You realize, I hope, that the bitrate of a TCP connection is inversely proportional to the connection’s RTT (round-trip-time); e.g., see
> 	https://www.switch.ch/network/tools/tcp_throughput/
> 
> It’s also important to understand that - with our software - you are streaming datagrams, which means that - even if you’re encapsulating them within a TCP connection - you have to be prepared for the possibility of some of these datagrams being lost.  It’s important to understand the difference between transmitting a stream - which occurs at a fixed data rate, regardless of what kind of network you happen to have underneath you - and downloading a file (i.e, the World-Wide Web), which occurs over TCP connections whose speed automatically matches the speed of the underlying network.  We’re doing the former; not the latter.
> 
> Streaming over TCP is generally a bad idea; it’s something that you should do only as a last resort, if you have a firewall - between your back-end server and proxy server - that blocks UDP packets.
> 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel




More information about the live-devel mailing list