CS 508 Data Communication Network Fall 2015

Research by (Peter) Donghyeok Shin & Joseph Durant

December 15th, 2015

“TCP & UDP Streaming Comparison and a Study on DCCP & SCTP Protocols” 1. INTRODUCTION This research is to demonstrate the differences between TCP & UDP streaming, using the practical case of providing video to the end user. There are many scientific measuring tools like NS-2 to compare network performances using simulated or real environments [1], however, this research is motivated to do actual experiment on video streaming, and document it using simple methods. In the midst of doing actual experiments, we have learned about another protocols like DCCP & SCTP. They are the variations of UDP protocols with the history of attempts at improving their reliabilities with the goal to replace traditional protocols. Even though it wasn’t successful for us to expand our experiments to include more actual tests on DCCP & SCTP due to various reasons, this project would like to introduce DCCP & SCTP and recognize their presence in Linux kernel. At this moment, the pace of improvement seems to be slow for DCCP & SCTP advancement, but the early researches provide their potential advantages over the traditional protocols based on their experiments. 2. ENVIRONMENT While TCP is always meant to be more reliable and has more quality than UDP, in case of real-time live media streaming, UDP has an advantage over TCP in terms of speed. With the motivation to demonstrate such notion about the differences between TCP & UDP media streaming, we configured proper testing environment which could compare only TCP & UDP protocols’ speeds, while other factors were identical. There were three factors which should be same among TCP & UDP streaming:

- Streaming application: Media streaming involves many tasks including encoding and

fragmenting data. If we used 2 different applications, it could be difficult to guarantee that only protocol switching affected the streaming speed. Thus, one application with the capability to switch between TCP & UDP was required. In our case, we tried both VLC and GStreamer. Since VLC was too slow due to using only CPU processing and had unknown errors which wasted our time, GStreamer was selected to be used for streaming application.

- Video capturing: Fortunately, in case of using Raspberry Pi camera, the uniform capturing command, raspivid, could be used to generate the output data to be streamed out by GStreamer.

- Network topology: Two different topologies were used to highlight the characteristics of TCP

& UDP.

- First one was configured to be WiFi 1-hop connection; Macbook as the client and Raspberry Pi as both an access point and streaming server were used. The physical distance between Raspberry Pi’s WiFi dongle and Macbook was about 12 inches (Fig. 1).

Fig. 1 WiFi 1-hop topology

- In the second topology, the network has 2-hops, and the physical distance between Raspberry Pi and the WiFi router was about 7 feet and from the router to Macbook was about 7 feet too. Total physical distance was about 14 feet.

Fig. 2 WiFi 2-hop topology

3. EXPERIMENTATION As the testing procedure, for about 1 minute, a stopwatch onscreen was captured by Raspberry Pi camera. raspivid captured 1920x1080 H.264 video was streamed out using GStreamer with TCP or UDP protocols. On the same screen, the client displayed the received video behind the onscreen stopwatch to compare the visible latency. And Macbook screen recorded the procedure. As a specification, the following equipment can be used:

• Streaming server (Raspberry Pi B+ with camera module) • Server & Client Streaming application (GStreamer) • Streaming client (e.g. Macbook laptop) • WiFi Router (e.g. iPhone’s Personal Hotspot) • Screen capturing application (e.g QuickTime)

Using Terminal in Raspberry Pi and Mac OS, you can copy-paste-execute following instructions. 1) Install GStreamer 1.0 in Raspberry Pi B+ and Macbook

Assuming Raspberry has the commonly available Raspbian as OS, you can install GStreamer 1.0 using apt-get in Raspberry Pi sudo apt-get install gstreamer1.0 In Macbook, it’s recommended to install Homebrew first. Homebrew is Mac OS’s equivalent to Linux’s apt-get [2] ruby -e "$(curl –fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

12in

1-hop

7ft 1-hop

7ft 1-hop

After installing Homebrew, you can install the same GStreamer brew install gstreamer

2) Configure network topologies

WiFi 2-hop configuration is actually easy. You can just use a WiFi router to have both Raspberry Pi and Macbook under same network. However, configuring 1-hop between Raspberry Pi and Macbook involves setting Raspberry Pi to operate like an access point, being a router by itself. An application created by Shaba Abhiram [3] can make Raspberry Pi as an access point. For not being within the scope of this project, you can refer to the detailed instructions in the link: https://github.com/sabhiram/raspberry-wifi-conf

3) Start streaming captured video from Raspberry Pi

Using the pipelined commands of raspivid and gst-launch-1.0, Raspberry Pi can stream captured video. For TCP streaming: raspivid -n -w 1920 -h 1080 -b 4500000 -fps 30 -vf -hf -t 0 -o - | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=***.***.***.*** port=9000 Instead of ***.***.***.***, use the actual IP address of Raspberry Pi. For UDP streaming: raspivid -n -w 1920 -h 1080 -b 4500000 -fps 30 -vf -hf -t 0 -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-interval=10 pt=96 ! udpsink host=###.###.###.### port=9000 But for UDP streaming, instead of ###.###.###.###, the IP address of the client computer (Macbook’s, Not Raspberry Pi’s!) should be entered.

4) Start client side’s gst-launch-1.0 to receive streaming video

To receive TCP streaming: gst-launch-1.0 -v tcpclientsrc host=***.***.***.*** port=9000 ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false ***.***.***.*** is the same IP address of Raspberry Pi from the previous command. To receive UDP streaming: gst-launch-1.0 -v udpsrc port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false

Notice no IP address is used, since the server sends UDP unicast streams targeted to the client

5) Record screen activities

When the streaming from the server is successfully received by the client, a video display will appear. Start a stopwatch application in client’s display and capture it using Raspberry Pi. By doing so, the display of original stopwatch, and the display of captured and streamed stopwatch can be shown in the same screen. Position them to be compared and start recording the video streaming using QuickTime [4].

Followings are the links to YouTube uploads, showing the resulting recorded videos:

• TCP 1-hop: https://youtu.be/AiOKOAovja0 • UDP 1-hop: https://youtu.be/WWDXgXUU5Xk • TCP 2-hop: https://youtu.be/BQ3zqmYOZ5o • UDP 2-hop: https://youtu.be/Q_tEOCyx5mI

4. EVALUATION Using the first topology with one hop, at about 30 seconds, the latency in TCP streaming is about 0.3s (Fig. 3), and in UDP is about 0.2s (Fig. 4). The difference is too small to be visible to human eyes. Though the observation is limited by not using a scientific measuring tool, it’s reasonable to assume that the unrealistically ideal network topology of having just 1-hop masked the different characteristics of TCP & UDP

Fig. 3 TCP 1-hop latency Fig. 4 UDP 1-hop latency

Fig. 5 TCP 2-hop latency Fig. 6 UDP 2-hop latency

However, the second topology which has only a small difference of having just one more hop, presented visible differences between TCP & UDP characteristics. At about one minute, TCP streaming became about 8.393s slower than the real stopwatch time (Fig. 5). But on the other hand, UDP streaming was only about 0.313s slower (Fig. 6). Even though we couldn’t graph it, the latency in TCP streaming was becoming larger as the video capturing continued. While UDP performed significantly faster, the quality of media had to be sacrificed. Being depicted obviously in UDP 2-hop video, frame skipping and image degradation happen for the streaming to keep up with the real time. Based on these results, we can assume that, in multi-hop network topology, UDP streaming can be much faster than TCP when following up to the real live time, but it compromises the quality to achieve such speed. In conclusion, depending on network condition and the purpose of streaming, both TCP & UDP has their own advantages. Further experimenting is suggested with more challenging network topology. The new topology should have more hops, larger physical distances, and a few more obstacles between Raspberry Pi and Macbook. 5. TCP Slowdown and UDP Skipping During our presentation in class showcasing the differences between TCP and UDP protocol there were two interesting occurrences. In the case of TCP, the stream program gradually lagged behind the real-time event, milliseconds at first though the lag became far more noticeable when it became evident that the stopwatch on the stream started to lag behind in seconds. UDP was a different experience, despite the notable lower quality the stream and real-time stopwatch stayed in sync (being a couple of milliseconds off, at most, due to latency) for a couple of seconds at a time. However, every couple of seconds it would inevitably slow down (as the quality would degrade further and further) until it blacked out completely before the stream once more resumed at the current tick of the stopwatch. Regarding TCP, slowdown is largely in part due to buffering. During the buffering phase, before streaming actually begins, TCP collects a certain portion of packets to act as a buffer. Should the connection or stream be interrupted in anyway the protocol will be able to access the buffer and continue streaming unhindered while it addresses the source of the problem (ex. in the case of packet loss, it would occur during packet retransmission). Despite the buffer, because TCP emphasizes receiving all packets and in their proper order it becomes very much likely for the stream to lag behind. Though TCP is capable of accessing buffers to combat this, it does not always ensure that speed will remain static. As such, the speed of streaming media will slow down just slightly as more and more packets must be sorted, the speed decrease becoming more and more prominent as the backlog of packets (due to latency and/or retransmission) increases. In the end, should the backlog become too severe or the connection worsens to the point where packets are unable to be reliably transmitted the connection will be forced to timeout. As for UDP, stream begins and continues regardless of the number of packets received and whether or not they come in order. Naturally, this leads to a notable drop in quality compared to TCP but allows the stream to maintain synchronization with real time. As the stream continues, quality will distort based on packet speeds (which can be hindered due to latency), as such the protocol becomes faced with two decisions on how to handle packets: either accept faster packets and wait for slower ones (which results in notable lapses in quality, such as the stream speeding up and

slowing down) or accept the faster packets and drop slower ones completely (which leads to data loss, skipping depending on how much data was lost). 6. STUDY ON DCCP/SCTP ADAPTABILITY Whereas the TCP/UDP comparison remained at the forefront of the project, research had gone into finding a third protocol to interact with (something others in the class might not have heard of so that they will be able to learn and take something away from the demonstration). Going forward, Reliable User Datagram Protocol (RUDP) was looked into as an interesting way to show an example to the class of a protocol that could potentially be standardized and implemented in the future. As a way of combining the quality of TCP with the speed of UDP it would have made for an interesting comparison during our data transfer quality demonstration (via sending a digital image of a clock face) with the Raspberry Pi. Unfortunately, RUDP (which incidentally was proposed all the way back in 1999 [5]) is not considered a formal standard nor have we been able to come across a proper implementable instance of it for the project After a bit more research, Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP) have been proposed as a means of comparison to TCP and UDP, though both have proven to be tricky to implement considering that the streaming module we are using (gstreamer 1.0) is only configured for TCP, UDP, and RTP. SCTP provides a two-way reliable communication that emphasizes quality (making it more similar to TCP in that regard) whereas DCCP seeks to organize the flow of packets within a UDP connection (making it more similar to UDP, but with a touch more reliability). Of the two, SCTP appears to be far more difficult to implement into existing code considering it requires additional system calls (example. sctp_bindx() ) whereas DCCP requires only the addition of a couple of headers and a redefinition of the socket() system call (ex. socket(PF_INET, SOCK_DCCP, IPPROTO_DCCP). Research then involved looking into how to take these protocols and implement them in the current streaming framework we have that works with TCP/HTTP and UDP/RTSP, however this has proven difficult due to overall lack of support of lesser-known protocols. 7. ATTEMPTED TESTING ON DCCP/SCTP Using the same testing environment used for TCP & UDP, we attempted to test DCCP/SCTP in actual video streaming. We expected a simple modification on the streaming application to use DCCP or SCTP would assist us in our testing. However, we couldn’t enable the additional protocols for the streaming application that was used, nor could we find an acceptable alternative approach. We’ve found that the Linux-Magazine article we wanted to follow [6] was outdated, being about 7 years. In the article, it introduced a GStreamer Plug-in, but it is not currently supported and no longer maintained by Nokia, stopping its development at around 2007 [7]. Also, by the decision makers of GStreamer, the current plug-in has been categorized to be bad (i.e. unusable) [8]. Within the given time for this project, we were not able to find good implementation of DCCP or SCTP for us to test video streaming. At the time of the initial proposal at around 2007, it was expected to replace UDP. However, while learning more about DCCP and SCTP, we have realized that they were not as reliable as they should be, and have been even disabled by default in Linux kernel for a long time.

We assume, the case of streaming media file has focused more on improving TCP speed, instead of UDP reliability. Also, the inconveniences of having insufficient API documentation and being inflexible, meaningful and practical application development couldn’t progress significantly. In general, video streaming problem has not advanced by using different protocols like DCCP or SCTP, but instead by increasing essential network speed overall. 8. SCTP In our endeavor to find an apt third protocol to compare, as stated before our investigations led not only to DCCP but also SCTP. Introduced in 2000 (and later updated in 2007 [9]), SCTP (Stream Control Transmission Protocol) was developed as a means to bypass the limitations of TCP such as its stream-oriented nature and vulnerability to denial of service attacks [10]. Forsaking the connection-based aspect of TCP, SCTP seeks to provide the speed of UDP (via support of out-of-order packet delivery) while retaining the congestion control properties of TCP. To accomplish this, SCTP is capable of handling multiple streams of data simultaneously (whereas TCP is only capable of one at a time), with controls and capabilities for handling each individual stream [11]. It also happens to be far better equipped to handle denial of service attacks than TCP due to rules in place (such as preventing half-open connections) that make it more resilient to flood-based attacks (multiple connection requests, for example). Furthermore, SCTP is capable of ‘multihoming’ which essentially allows each stream to connect to its own IP address (allowing for an individual to walk out of range from one WiFi connection into another and not once lose connection so long as there are streams connected to each). Though it may seem to provide the best of both TCP and UDP (and even surpasses them in certain aspects) the challenge with SCTP resides in its difficulty of implementation, specifically the requirement of modifying the code for client and server applications to allow it to handle both an SCTP-based connection, and multiple simultaneous streams (though it should be noted that such is already integrated within Linux OS). All in all, its relative obscurity is largely in part due to the familiarity of TCP and UDP. Its implementation difficulties only work against it in a world of devices and software developed with only the more popular protocols in mind. Despite its notable benefits, it simply isn’t practical to go into the code of every application and modifying it to support SCTP. Note that this is not only an issue of SCTP but many of the uncommon protocols (as this is an issue we’ve run into with DCCP as well, the lack of support); with so many applications coded to work only with TCP and UDP it will be difficult for another to gain a foothold without the means of easier implementation. 9. EXCERPTED RESEARCH EVALUATIONS Due to being unable to do our own tests on DCCP/SCTP protocols, we would like to present excerpted research evaluations from the paper, “Performance Evaluation of DCCP and SCTP for MPEG4 Video over Wireless Networks”, by S. Nosheen et al.[12]. Using a simulator, NS-2, the paper conducted performance tests for the case of streaming MPEG-4 video. Since the paper’s test environment is similar to our WiFi 2-hop topology (Fig. 7), it seems appropriate to use their research evaluations on DCCP/SCTP to complement the missing part of our project. In terms of throughput, DCCP performed better than UDP and SCTP (Fig. 8). SCTP performed as good as DCCP up to 4.11Mbps but began to lose more packets than UDP as video rate increased.

Due to losing only less than about 13.171 % of packets at 7 Mbps rate, it wasn’t difficult to confirm that DCCP performed better for successful packet delivery.

Fig. 7 Similar Topology Fig. 8 Throughput

Fig. 9 Delay Fig. 10 Jitter (Delay Deviation)

Also, in terms of delay, DCCP performed significantly better than UDP, along with SCTP (Fig. 9). SCTP’s performance was affected by having reliability and congestion controls, however, still up to about 3Mbps, it could perform as good as DCCP. Event though, DCCP showed drastic widening after 5 Mbps, still it performed better than other protocols in terms of jitter (Fig 10). S. Nosheen et al.’s paper concluded that DCCP could perform better than other protocols for the quality of service. However, since the experiments were conducted using just simulators, it’s still speculative to consider DCCP to perform significantly better in real world application. Also, due to the contradiction between the paper’s hopefulness at the year of its publication (2007) and current adoption status of DCCP and the issues addressed in the paper, “Using DCCP: Issues and Improvements,” by M. Schier and M. Welzl, it will take a long time to see DCCP being used as ubiquitously as it hoped.

applications, users often prefer bursts of static to choppy rebuffering delay; in games, only the latest position information matters. DCCP meets all features of modern TCP congestion control protocol, including selective acknowledgments, explicit congestion notification (ECN), acknowledgment verification, and so forth, as well as obvious extensions hard to port to TCP, such as congestion control of acknowledgements. Currently DCCP uses TCP-like congestion control mechanism. As in TCP, DCCP implementation should be able to manage congestion control without application aid. DCCP receivers must detect congestion events without application intervention; DCCP senders must calculate and enforce fair sending rates without application cooperation. Any API for sending DCCP packets will support some buffering, allowing the operating system to smooth out scheduling bumps. However, when the buffer overflows- the application’s send rate is more than congestion control allows- a smart application may want to decide exactly which packets should be sent. Some packets are more valuable than others (for example audio data might be preferred to video), or newer packets preferred to older ones. As explained above DCCP provide bidirectional connection: data and acknowledgements flow in both directions. However, many DCCP applications will have fundamentally asymmetric data flow. For example in streaming media almost all data flows from server to client; after the initial connection setup, the client’s packets are all acknowledgements.

III. SIMULATION MODELING AND ANALYSIS

A. Introduction In order to evaluate which transport protocol is suitable for

real time video traffic, we explore the performance of SCTP, DCCP and UDP in wireless network for the multimedia application (video). Extensive set of simulations are carried out in Network Simulator ns-2 [9] simulator and “MPEG4” video traffic model is used. Performance parameters or matrices used are Throughput, Packet loss, Delay and Jitter.

B . Simulation Tool Network Simulator, ns-2 is an object-oriented, discrete event

driven network simulator developed at UC Berkely written in C++ and OTcl. Network Simulator is primarily useful for simulating local and wide area networks. Network simulator covers a very large number of applications, protocols, network types, network elements and traffic models.

C. Traffic Model (video) MPEG4 is the one that is most suitable for the Internet. It is

targeted for low bit rates. It allows real images to co-exist with computer-generated counterparts and also allows their separation and their receiving different treatment due to interaction with the user. The main feature of importance to the network is MPEG4’s capability of real-time adaptive encoding. This enhances network utilization and enables MPEG4 senders to be more responsive to changes in network conditions. It

generates video in three different frame types (I, P, and B) that serve to encode different portions of the video signal in different levels of quality. We used a traffic generator developed [10]. In the simulation the MEPG4 (video) rate can be increased or decreased by changing the value of rate factor variable. D. Performance Metrics 1. Throughput

The amount of data transferred from Sender to Receiver in a specified amount of time. In our experiment we take the throughput as:

Number of Received Bits / Simulation Time-------- (i)

2. Delay The amount of time by which an event is retarded. The delay

definition according to our experimental setup is: Packet j – Packet i-------------- (ii)

Where j = current packet i= previous packet

We are calculating mean delay in our experimental setup.

3. Jitter Instantaneous jitter is calculated by using formula given below:

Delay of Packet j – Delay of Packet i ------------ (iii) We are taking average of instantaneous jitter.

4. Packet Loss Packet loss is defined as

Number of packets send – Number of packets received----- (iv)

E. Experimental Results and their Analysis a. Experimental Setup We simulate a WLAN based on IEEE 802.11b with 11Mbps. Wireless LAN consist of three nodes sender and receiver with one access point(AP).node_1 acts as a sender node and node_2 acts as a receiver node.node_0 is a center node, act as an access point between node_1 and node_2. Any data generated by the sender node must routed through the central AP node i.e. node_0 and then packets routed towards the destination node.

Fig 4.

Figrue1. Wireless LAN Setup

Packet size is 1500 bytes. DropTail/PriorityQueue is used and Queue size is 500 packets. Real time MPEG4 video traffic is running between the nodes via AP node. Send rate for the video traffic increases as 2Mbps, 3Mbps, 4Mbps and 5Mbps that means transmission/send rate is

node_1 Sender

MPEG4 node_0

MPEG4 Receiver

node 2

AP

incremented by 1Mbps each time. In ns-2, MPEG4 traffic rate can change by changing the rate factor variable. In our scenario, we have increased the rate factor as 5.0, 10.2, 15.0, 20.0 and 25.0. For 2Mbps, the rate factor is 5.0 and then it increases accordingly.

b. Experimental Results 1. Throughput

TABLE 1. THROUGHPUT COMPARISONS OF SCTP, DCCP AND UDP

Throughput rate in Mbps Video send rate SCTP UDP DCCP

2Mbps 2.0 1.702 2.0 3Mbps 3.0 2.44 3.0 4Mbps 4.0 3.12 4.0 5Mbps 4.11 3.99 4.777 6Mbps 4.11 4.26 5.729 7Mbps 4.11 4.26 6.078

In Table 1 for video traffic load of 2Mbps to 4Mbps, throughput or receive bit rate is equal to the send rate and packet loss is equal to zero. Up to 4Mbps of video send rate, SCTP and DCCP show an excellent performance for video traffic. But throughput achieved by UDP is 22% less than both SCTP and DCCP. This is because percentage of packet loss in UDP is very high and due to unreliable performance of this protocol. As traffic further increased from 4Mbps onwards, SCTP experiences more packet drop and its throughput decreases. For 5Mbps of video traffic rate, throughput achieve by DCCP is 25% more than SCTP i.e. DCCP achieves 4.777Mbps of throughput and SCTP achieves 4.11Mbps.There is no further increase in SCTP throughput beyond 4.11Mbps for an increase in video send rate. But maximum throughput experience by DCCP is up to 6.078Mbps of for video send rate up to 7Mbps.

0

1

2

3

4

5

6

7

2M bps 3M bps 4M bps 5M bps 6M bps 7M bps

video rate

Thro

ughp

ut (M

bps)

SCTPDCCPUDP

Figure 2. Throughput comparisons of SCTP, DCCP and UDP

2. Packet Loss

TABLE 2. PACKET LOSSESVideosendrate

SCTP UDP DCCP Mbps Percentage Mbps Percentage Mbps Percentage

2Mbps 0 0% 0.298 14.9% 0 0% 3Mbps 0 0% 0.56 18.66% 0 0% 4Mbps 0 0% 0.88 22% 0 0% 5Mbps 1.4869 30% 1.01 20.2% 0.223 4.46% 6Mbps 1.4869 41.44% 1.74 29% 0.271 4.516 % 7Mbps 1.4869 49.812% 1.74 39.14% 0.922 13.171%

Table 2 shows the packet losses. DCCP experiences very small packet loss as compared to SCTP. For instance for 5Mbps of video traffic load, packet loss experience by SCTP is 30% and of DCCP is 4.46%. These results show that performance of DCCP is better than SCTP in terms of packet loss and throughput.

3. Delay

TABLE 3. DELAY COMPARISON OF SCTP, DCCP AND UDP

Video send rate SCTP UDP DCCP 2Mbps 17.8388 10.9094 4.351441 3Mbps 24.1002 16.4433 7.421933 4Mbps 108.94 26.673 10.52609 5Mbps 143.037 103.512 15.88703 6Mbps 143.037 1159.01 29.5149 7Mbps 143.037 1159.01 29.5149

As shown in the Table 3. DCCP experiences minimum average delay as compare to both SCTP and UDP. For 4Mbps of video send rate, the average delay experiences by three protocols are as fallows, DCCP is 10.526ms, SCTP is 26.673ms and UDP is 108.94ms.

For all other cases we obtained similar results that delay experiences by DCCP is less than UDP and SCTP. SCTP experiences largest delay. This is due to the congestion control mechanism of the SCTP. The reliability feature of SCTP consumes time so cost of reliability in SCTP is in term of time.

0

200

400

600

800

1000

1200

1400

2Mbps 3Mbps 4Mbps 5Mbps 6Mbps 7Mbps video rate

Del

ay (m

sec)

SCTPUDPDCCP

Figure 3. Delay comparisons of SCTP, UDP and DCCP

incremented by 1Mbps each time. In ns-2, MPEG4 traffic rate can change by changing the rate factor variable. In our scenario, we have increased the rate factor as 5.0, 10.2, 15.0, 20.0 and 25.0. For 2Mbps, the rate factor is 5.0 and then it increases accordingly.

b. Experimental Results 1. Throughput

TABLE 1. THROUGHPUT COMPARISONS OF SCTP, DCCP AND UDP

Throughput rate in Mbps Video send rate SCTP UDP DCCP

2Mbps 2.0 1.702 2.0 3Mbps 3.0 2.44 3.0 4Mbps 4.0 3.12 4.0 5Mbps 4.11 3.99 4.777 6Mbps 4.11 4.26 5.729 7Mbps 4.11 4.26 6.078

In Table 1 for video traffic load of 2Mbps to 4Mbps, throughput or receive bit rate is equal to the send rate and packet loss is equal to zero. Up to 4Mbps of video send rate, SCTP and DCCP show an excellent performance for video traffic. But throughput achieved by UDP is 22% less than both SCTP and DCCP. This is because percentage of packet loss in UDP is very high and due to unreliable performance of this protocol. As traffic further increased from 4Mbps onwards, SCTP experiences more packet drop and its throughput decreases. For 5Mbps of video traffic rate, throughput achieve by DCCP is 25% more than SCTP i.e. DCCP achieves 4.777Mbps of throughput and SCTP achieves 4.11Mbps.There is no further increase in SCTP throughput beyond 4.11Mbps for an increase in video send rate. But maximum throughput experience by DCCP is up to 6.078Mbps of for video send rate up to 7Mbps.

0

1

2

3

4

5

6

7

2M bps 3M bps 4M bps 5M bps 6M bps 7M bps

video rate

Thro

ughp

ut (M

bps)

SCTPDCCPUDP

Figure 2. Throughput comparisons of SCTP, DCCP and UDP

2. Packet Loss

TABLE 2. PACKET LOSSESVideosendrate

SCTP UDP DCCP Mbps Percentage Mbps Percentage Mbps Percentage

2Mbps 0 0% 0.298 14.9% 0 0% 3Mbps 0 0% 0.56 18.66% 0 0% 4Mbps 0 0% 0.88 22% 0 0% 5Mbps 1.4869 30% 1.01 20.2% 0.223 4.46% 6Mbps 1.4869 41.44% 1.74 29% 0.271 4.516 % 7Mbps 1.4869 49.812% 1.74 39.14% 0.922 13.171%

Table 2 shows the packet losses. DCCP experiences very small packet loss as compared to SCTP. For instance for 5Mbps of video traffic load, packet loss experience by SCTP is 30% and of DCCP is 4.46%. These results show that performance of DCCP is better than SCTP in terms of packet loss and throughput.

3. Delay

TABLE 3. DELAY COMPARISON OF SCTP, DCCP AND UDP

Video send rate SCTP UDP DCCP 2Mbps 17.8388 10.9094 4.351441 3Mbps 24.1002 16.4433 7.421933 4Mbps 108.94 26.673 10.52609 5Mbps 143.037 103.512 15.88703 6Mbps 143.037 1159.01 29.5149 7Mbps 143.037 1159.01 29.5149

As shown in the Table 3. DCCP experiences minimum average delay as compare to both SCTP and UDP. For 4Mbps of video send rate, the average delay experiences by three protocols are as fallows, DCCP is 10.526ms, SCTP is 26.673ms and UDP is 108.94ms.

For all other cases we obtained similar results that delay experiences by DCCP is less than UDP and SCTP. SCTP experiences largest delay. This is due to the congestion control mechanism of the SCTP. The reliability feature of SCTP consumes time so cost of reliability in SCTP is in term of time.

0

200

400

600

800

1000

1200

1400

2Mbps 3Mbps 4Mbps 5Mbps 6Mbps 7Mbps video rate

Del

ay (m

sec)

SCTPUDPDCCP

Figure 3. Delay comparisons of SCTP, UDP and DCCP

4. Jitter

TABLE 4.

JITTER COMPARISONS OF SCTP, DCCP AND UDP

Video send rate

SCTP UDP DCCP

2Mbps 0.00046 0.001171 0.001646

3Mbps 0.00058 0.00077 0.00409

4Mbps 0.00572 0.00028 0.003674

5Mbps 0.00496 0.00602 0.002949

6Mbps 0.00496 0.00602 0.007196 7Mbps 0.00496 0.00602 0.015383

Table 4 shows the jitter comparison of three protocols. At 4Mbps, jitter experience by SCTP is 0.00572ms, UDP experiences jitter of 0.00028ms and DCCP achieve 0.003674ms of jitter. Jitter value of DCCP is 0.002046ms times smaller than jitter of SCTP. Similarly at 5Mbps, jitter of SCTP is 0.001651ms times larger than DCCP. Here in jitter comparison DCCP again shows a better performance.

0

0.002

0.004

0.006

0.008

0.01

0.012

0.014

0.016

0.018

2Mbps 3Mbps 4Mbps 5Mbps 6Mbps 7Mbps

SCTPDCCPUDP

Figure 4. Jitter comparisons of SCTP, DCCP and UDP

F. Effect of Background Traffic in SCTP, UDP and DCCP Any traffic other than the video traffic in our setup is termed

as background traffic. In our established setup, we use the CBR as background

traffic. This section shows the effect of background traffic on delay and jitter. CBR traffic with different percentages, run in the background with video traffic and video traffic varies as 2Mbps, 3Mbps, 4Mbps and 5Mbps.

a. Effect of Background Traffic in SCTP 1. Delay Comparison

TABLE 5.1 EFFECT OF BACKGROUND TRAFFIC ON DELAY IN SCTP

CBR Traffic Video

send rate 16.66% 33.33% 50% 66.66% 83.33%

Average Delay (msec) 2Mbps 61.267 51.841 24.448 25.036 23.421 3Mbps 21.551 53.143 25.035 26.098 24.449 4Mbps 56.963 52.989 30.485 31.280 29.540 5Mbps 114.823 114.393 115.627 115.763 115.983

Table 5.1 shows the effect of background traffic on delay. For 50% of background traffic when video traffic rate is 2Mbps the delay is 24.448ms. For 3Mbps, it is 25.035ms, at 4Mbps, delay value become 30.485ms and for 5Mbps delay is 115.627ms. Table5.1 shows that, as video traffic increases the effectiveness of background traffic becomes more and causes an increase of average delay between the send and receive of video packets.

2. Jitter comparison

TABLE 5. 2. EFFECT OF BACKGROUND TRAFFIC ON JITTER IN SCTP

Percentage of CBR traffic in Background

Video traffic rate 2Mbps 3Mbps 4Mbps 5Mbps

16.66% 0.003888 0.000985 0.000573 0.004243 33.33% 0.001131 0.002021 0.000865 0.005324

50% 0.001128 0.001010 0.00149 0.006679 66.66% 0.001476 0.001981 0.000563 0.006726 83.33% 0.000583 0.001643 0.001869 0.006693

Table5.2 shows the effect on average jitter when bandwidth is shared by background traffic. It shows an inconsistent behavior for all the cases except for when the background traffic is 50%. For the 50% of the background traffic, a consistent behavior of jitter is observed. There is a continuous increase in the value of jitter when video traffic varies from 2Mbps to 5Mbps. An inconsistent behavior is observed, when background traffic is 16.66% and video send rate is 2Mbps, jitter value is equal to 0.003888ms but as video rate increases to 3Mbps, a sudden decrease in the value of jitter is observed which is equal to 0.000985ms. Similarly as video rate increases to 4Mbps, jitter value is further decreased to 0.000573ms and then it increases to 0.004243ms for 5Mbps of video send rate.

b. Effect of Background Traffic in UDP 1. Delay comparison

TABLE 6.1 EFFECT OF BACKGROUNG ON DELAY TRAFFIC IN UDP

CBR Traffic Video

send rate 16.66% 33.33% 50% 66.66% 83.33%

Average Delay (msec) 2Mbps 17.915 1073.236 1031.651 1070.121 1090.793 3Mbps 30.204 1086.042 1030.704 1061.679 1082.647 4Mbps 078.534 1106.207 1026.958 1057.515 1074.804 5Mbps 129.804 1113.103 1026.507 1054.354 1070.378

Table6.1 shows the effect of background traffic on delay when UDP is used as a transport protocol. When 16.66% of background traffic shares the bandwidth with video traffic, video rate varies as 2Mbps, 3Mbps, 4Mbps and 5Mbps and their respective average delay are 17.915ms, 30.204ms, 1078.534ms and 1129.804ms. This shows that there is an increase of average delay as the video send rate increases. But it is noticeable that the increase in average delay in UDP is comparatively very high as compare to average delay in SCTP. But for the 50%, 66.66% and 83.33% of background traffic a strange behavior is observed; as video traffic sends rate

CONCLUSION Though our work with TCP and UDP was fruitful, delving into lesser-known protocols proved to be a hindrance due to overall lack of support amongst applications. Due to how deeply engrained TCP and UDP are nowadays, it is difficult (if not downright impossible) for other protocols to become widespread and take hold. Those that do show promise (SCTP, for example) are either deemed far too difficult to implement, ignored due to the ease of implementing a TCP or UDP-based connection, or (as a result of the prior reasons) become so obscured that they’re not even known by the community at large. As such, it is not expected for TCP or UDP to be replaced anytime soon but rather for researchers to continue to work within the restraints of the protocols and find alternative methods to overcome their weaknesses (for example, improving network transfer speed to make up for TCP’s sluggishness rather than replacing TCP itself). That said, for the future it would be intriguing to actually have a chance to test out DCCP and SCTP first-hand rather than rely on research studies to have a glance at their quality. Such can be done either by researching a streaming application that supports DCCP/SCTP (though easier said than done), or draft a testing program of our own specifically coded to work with either of these two protocol. From the descriptions of the protocol themselves it appears quite plausible that either one is capable of surpassing TCP/UDP in performance (despite the statements of the research we’ve encountered), but due to the overall lack of support of applications actually finding a means to test this difference has proven to be exceptionally difficult.

REFERENCES [1] “The Network Simulator - ns-2”, University of Southern California. [Online]. Avaliable:

http://www.isi.edu/nsnam/ns/ [2] Brew.sh, "Homebrew The missing package manager for OS X", 2015. [Online].

Available: http://brew.sh [3] GitHub, "sabhiram/raspberry-wifi-conf", 2015. [Online]. Available:

https://github.com/sabhiram/raspberry-wifi-conf [4] Support.apple.com, "QuickTime Player 10.x: Record your computer’s screen", 2015.

[Online]. Available: https://support.apple.com/kb/PH5882?locale=en_US [5] Tools.ietf.org, "draft-ietf-sigtran-reliable-udp-00 - RELIABLE UDP PROTOCOL", 2015.

[Online]. Available: https://tools.ietf.org/html/draft-ietf-sigtran-reliable-udp-00 [6] L. Sales, "Congestion Control", Linux Magazine, 2015. [Online]. Available:

http://www.linux-magazine.com/Issues/2008/93/DCCP [7] Garage.maemo.org, "garage: Embedded-Phone: Project Filelist", 2015. [Online].

Available: https://garage.maemo.org/frs/?group_id=297 [8] Freedesktop.org, "GStreamer Bad Plugins 0.10 Plugins Reference Manual", 2015.

[Online]. Available: http://www.freedesktop.org/software/gstreamer-sdk/data/docs/latest/gst-plugins-bad-plugins-0.10/

[9] Tools.ietf.org, "RFC 4960 - Stream Control Transmission Protocol", 2015. [Online].

Available: http://tools.ietf.org/html/rfc4960 [10] Tools.ietf.org, "RFC 2960 - Stream Control Transmission Protocol", 2015. [Online].

Available: https://tools.ietf.org/html/rfc2960#section-1 [11] S. Hogg, "What About Stream Control Transmission Protocol (SCTP)?", Network

World, 2015. [Online]. Available: http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html

[12] S. Nosheen, S. A. Malik, Y. Bin Zikria, and M. K. Afzal, “Performance Evaluation of

DCCP and SCTP for MPEG4 Video over Wireless Networks Multitopic Conference, 2007. INMIC 2007. IEEE International,” Multitopic Conf. 2007. INMIC 2007. IEEE Int., pp. 1–6, 2007.

[13] M. Schier and M. Welzl, “Using DCCP: Issues and Improvements,” no. Section IV, pp.

1–9, 2012.