1. SPDY’S PERFORMANCE IN REAL TIME VIDEO
STREAMING VERSUS RTSP’S PERFORMANCE
Olaniyi Q. Jinadu
2014
I. INTRODUCTION
SPDY is a network protocol developed by Google to
enhance, and in time, replace HTTP in the transfer of
web content to improve web page load latency. Due to
the fact that SPDY uses one single TCP connection per
domain [1]
, it can send multiple data streams on the same
connection. SPDY [1]
also has features which allow data
to be pushed onto the connection before the data is
requested by the client, and another that prepares
unrequested data to be sent before they are requested.
Alongside these features, SPDY also has fewer packets
in its header and allows clients to prioritize their request
so the most important objects/file arrives first. This has
led to an improvement in web latency over the web but
the behavior of SPDY over TCP have not been
convincing enough to certify it as a replacement for
HTTP yet, especially on cellular networks [2]
. Most tests
carried out on SPDY have been focused on the transfer
of objects, but the internet users today have an
increasing need to stream, view, download and transfer
media content in form of video which saw YouTube
accumulate a total of over 700 billion videos streams in
2010[3]
, so any changes made to improve web latency
will have to take video media streams into consideration
as well. Because of this increasing need to stream video,
a new protocol Real Time Stream Protocol (RTSP) is
used to stream videos because this provides a more
interactive interface where the user does not have to wait
for the whole video to download before the user can
watch it, which is the case on video streaming over
HTTP [5]
. RTSP allows the user to jump back and forth,
skipping through different parts of the video without
having to download the whole video. So because of the
increasing use of RTSP, this paper will focus on the
comparison of SPDY to RTSP.
II. REAL TIME STREAMING PROTOCOL
(RTSP)
RTSP is a protocol used by most content delivery
servers to transmit content, in this case, videos, to the
client. RTSP has been considered as the remote control
protocol [4]
because it is responsible for the control
system we have on most real time streaming video
players today. So basically the RTSP controls a stream
of data that can be carried on a different transport
protocol than the one RTSP is running on. For example,
RTSP could be running on TCP or RTP but choose to
send the data stream on UDP. Even though in some
cases, RTSP runs alongside HTTP, RTSP has been
chosen over HTTP in recent years when it comes to
video streaming because of different ways in which it
differs from HTTP. Some of the key differences can be
seen below [7]
;
1) HTTP runs on TCP which means no packet is ever
lost. When a packet from the data stream is lost, the
player buffers and waits for a retransmission since
this is how TCP behaves. RTSP on the other hand
can run on any transport protocol and stream on
another. So in a situation where the integrity of the
video is not priority, RTSP can run on TCP to
establish a safe and stable connection but the data
stream can be sent via UDP so that when a packet is
lost, the video continues and this will only show as a
reduction in picture quality on the video at that very
moment while transmission of other packets
continue without interruption.
2) Since RTSP does not care about packets being lost it
has a forward error correction scheme which is not
needed in HTTP since HTTP runs on TCP, and
every packet is delivered to the client.
3) RTSP needs multiple request messages before the
video stream can begin but all the requests can be
multiplexed on one TCP connection wile HTTP
steaming uses on TCP connection per request
message because most proxy servers do not support
pipelining.
The features above are similar to the some
improvements Google proposed in SPDY to optimize
web performance so it is interesting to see if SPDY’s
additional features will make it a better protocol when it
comes to real time video streaming.

2. III. EXPERIMENTAL SET-UP
The experiment to compare the performance of RTSP
and SPDY in regards to real time video streaming was
conducted over a period of 2 weeks.
The client is connected using SPDY or RTSP and SPDY
or HTTP proxies respectively to fetch and stream
different videos of different lengths, sizes and quality.
Proxy servers were used because not all sites run SPDY
and websites like YouTube that do, do not run HTTP as
a result. So in other for the experiment to be as fair as
possible to both protocols, they have to be tested with
the same videos using proxy servers to fetch these
videos.
A PC running Windows 7 and Google Chrome were
used for the experiment and due to lack of resources, the
experiment had to be conducted on the same PC at
different times of the day. A wireless internet was used
as this allows for the results to be applicable to the real-
world. Wireshark was used to observe the packet flow
and the lengths of the videos ranged from 3 – 10
minutes.
IV. EXPERIMENTAL RESULTS
The graphical representation above are the plotted results
of SPDY and RTSP’s latency test over a period of 100
simulations with a high definition (720p) video whose
length is ~ 5 minutes. As we can see, there are periods
when SPDY outperforms RTSP and vice versa but this
result is inconclusive because of the limited number of
test runs and the lack of simultaneous test runs. The
variation in bandwidth at different times is also a huge
factor that was neglected while conducting this
experiment because of the lack of ready and affordable
resources. But it is safe to say that the features available
on SPDY are not sufficient enough to render SPDY as a
replacement of HTTP when it comes to real time video
streaming.
V. SUMMARY AND CONCLUSION
The similarities between RTSP and SPDY such as the
fact that they can both multiplex their request messages
on one TCP connection have made SPDY and RTSP
behave similarly in this experiment. Even though SPDY
streams it data on TCP connection and there is buffering
when a packet is lost, the difference in performance in
the two protocols is not significant enough to declare
SPDY or RTSP a better protocol.
VI. FUTURE IMPROVEMENTS
Due to lack of resources the experiment and analysis of
SPDY versus RTSP could not be observed at the same
time. As much as I tried to run as many simulations as I
could, this lack of simultaneous experimentation does
add some inconsistency to the results so in the future
using similar multiple PCs and running the experiment
on them via SPDY and RTSP will give us a more
accurate result. The simulation runtime too is a part of
the experiment that can be improved; two weeks is not
enough time to collect adequate results that will
accurately model the behavior of both protocols.
In addition, the role of P2P video streaming networks
and CDNs has to be taken into account in future
experimentations. Because these two networks are being
used by a lot of content providers to effectively and
efficiently utilize available bandwidth [6]
, as well as, to
reduce the round-trip time of packets to improve clients’
real time video streaming experience.
VII. REFERENCES
[1] Google. SPDY: An experimental protocol for a faster
web. http://www.chromium.org/spdy/spdy-whitepaper
[2] Towards a SPDY’ier Mobile Web? Jeffrey Erman,
Vijay Gopalakrishnan, Rittwik Jana, K.K. Ramakrishnan
[3]YouTube Everywhere: Impact of Device and
Infrastructure Synergies on User Experience. Alessandro
Finamore, Marco Mellia, Maurizio M. Munafò
[4] Real Time Streaming Protocol (RTSP). H.
Schulzrinne. http://www.ietf.org/rfc/rfc2326.txt
[5] On Media Delivery Protocol in the Web. Davy Van
Deursen, Wim Van Lancker, Rik Van de Walle
[6] A P2P Video Delivery Network (P2P-VDN). Kien
Nguyen, Thinh Nguyen, Yevgeniy Kovchegov
[7] Comparing HTTP Streaming Protocol with RTSP
(Windows Embedded CE 6.0).
http://msdn.microsoft.com/en-
us/library/ee485306(v=winembedded.60).aspx
0 10 20 30 40 50 60 70 80 90 100
300
350
400
450
500
550
600
Performance of SPDY Vs. RTSP
Test Run
Latency(inms)
SPDY
RTSP