53 CHAPTER 3 PERFORMANCE ANALYSIS OF TRANSPORT PROTOCOLS TCP, UDP, SCTP AND DCCP VARIANTS 3.1 INTRODUCTION In general, the performance of the congestion control algorithms of the presently available internet transport protocols for wired, wireless and mobile ad hoc networks, are found highly reliable under certain scenarios. Also, their performance is not found satisfactory under a high density sensor network application since, they are not designed for sensor networks in mind. To determine a best suited algorithm for a sensor network it is proposed to analyze the performance of some of the standard transport protocols on a congested sensor network environment. The protocols selected for this purpose in this research work are TCP, UDP, SCTP, DCCP-TCP-like and DCCP-TFRC. To estimate the performance of any proposed system in the field of engineering and technology, finding a suitable model of the system using any of the proven modeling techniques, with the minimum permitted deviation from the actual scenario, is the first step. This is followed by simulating the model using a simulation tool with a degree of compromise such that the results obtained from the simulation by and large reflects the actual values. Hence, a brief overview of the NS2 simulation scenario over which the proposed transport protocols are to be implemented and the standard metrics used to estimate their performances are also given in this chapter.
31
Embed
CHAPTER 3 PERFORMANCE ANALYSIS OF TRANSPORT PROTOCOLS …shodhganga.inflibnet.ac.in/bitstream/10603/22616/8/08_chapter3.pdf · 53 CHAPTER 3 PERFORMANCE ANALYSIS OF TRANSPORT PROTOCOLS
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
53
CHAPTER 3
PERFORMANCE ANALYSIS OF TRANSPORT
PROTOCOLS TCP, UDP, SCTP AND DCCP VARIANTS
3.1 INTRODUCTION
In general, the performance of the congestion control algorithms of
the presently available internet transport protocols for wired, wireless and
mobile ad hoc networks, are found highly reliable under certain scenarios.
Also, their performance is not found satisfactory under a high density sensor
network application since, they are not designed for sensor networks in mind.
To determine a best suited algorithm for a sensor network it is proposed to
analyze the performance of some of the standard transport protocols on a
congested sensor network environment. The protocols selected for this
purpose in this research work are TCP, UDP, SCTP, DCCP-TCP-like and
DCCP-TFRC.
To estimate the performance of any proposed system in the field of
engineering and technology, finding a suitable model of the system using any
of the proven modeling techniques, with the minimum permitted deviation
from the actual scenario, is the first step. This is followed by simulating the
model using a simulation tool with a degree of compromise such that the
results obtained from the simulation by and large reflects the actual values.
Hence, a brief overview of the NS2 simulation scenario over which the
proposed transport protocols are to be implemented and the standard metrics
used to estimate their performances are also given in this chapter.
54
3.2 PROPOSED WSN SCENARIO
A typical WSN scenario over which the proposed protocols are to
be implemented to estimate their performances is depicted in Figure 3.1.
There are 57 nodes in the proposed scenario with one sink node or base
station and 50 normal nodes with relatively lesser transmission range. Seven
gateway nodes are provided to facilitate the information exchange between
sink node and normal nodes.
Figure 3.1 Proposed wireless sensor network
In the simulated sensor field the 0th node is the sink node. Nodes 1
to 7 are sensor nodes capable of communicating to sink node with relatively
higher transmission power. All other nodes are normal sensor nodes and can
transmit only for a short distance. The Transmission power of the sensor
1
0
8
9
1112
15
17
1813
15 16
17
18
19
20
22 23
24
25
26
27
10
14
21
38
42
41
36 37
40
43
45
28
29
32
13
35
39
30 33
3431 44
45
48
46
47
49
50
7
6
5
4
31
2
51
52
53
54
55 5657
Node 0 – Sink NodeNodes 1 to 7: Gateway Nodes Nodes 8 to 57: Normal Sensor Nodes
55
nodes and sinks are set based on the required transmission range, signal
frequency and other related parameters.
Table 3.1 Transmission range of nodes
S.No Node Type Range
1 Sink Node (Node 0) 150m
2 Gateway Nodes (Nodes 1 to 7) 150m
3 Normal Sensor Nodes (Nodes 8 to 57) 60 m
Table 3.2 Specification of sensor field
S.No. Parameter Value
1 Channel Wireless Channel
2 Propagation Two Ray Ground
3 Physical Medium Wireless medium
4 Antenna Omni Antenna
5 Routing Protocol AODV
6 MAC Type 802.11
7 Queue Drop Tail / PriQueue
8 Queue Size 50
9 Traffic Application CBR
11 Number of Nodes 57
12 Topographical Area 800 400 m
13 Simulation Time 100 sec
The energy model of NS2 is used to study the power drain
characteristics of the node. In the network simulated, sensor nodes send the
56
data to the sink in a periodic fashion as in the case of practical networks and
no cross traffic is taken into account during evaluation of the protocols. So,
the total sent and received packets will increase with respect to the increase in
reporting interval since, the overall simulation time is kept constant.
The different attributes of the various components of the sensor
field are set to the default values as specified by NS2. The transmission range
of different types of nodes and the specifications for sensor field are given in
Tables 3.1 and 3.2 respectively.
3.3 OVERVIEW OF PERFORMANCE METRICS
To estimate the performance of a system there are certain metrics
associated with the system under consideration and a range of desired values
for those metrics. These values of the metrics determine the quality of the
system and its suitability for the proposed objective. In similar lines, the
standard metrics considered in this work to evaluate the performance of WSN
employed with different protocols are Throughput, Energy Consumption,
Routing Load, MAC Load, Dropped Packets and End-to-End Delay.
3.3.1 Throughput
This metric defines the number of packets received by a destination
or sink over the given period of time. Obviously, a better congestion control
algorithm results in the delivery of good number of packets with respect to
time always. The unit for throughput is kilo bits per sec (Kbps).
3.3.2 Energy Consumption
The average energy consumed by all the nodes of the network is
considered as a metric to assess the performance of the congestion control
algorithms. The energy consumption of a node depends on several parameters
57
such as sensor data reporting interval, routing protocol, transport protocol,
congestion control algorithm of the transport protocol etc., and it is obvious
that the lower energy consumption signifies better congestion control
algorithm. The unit for this metric is Joules.
3.3.3 Routing Load
It is the number of routing packets required to transmit a data
packet successfully from a source to sink. A better congestion algorithm
provides a relatively lower routing load for the given amount of data packets.
The unit for Routing Load is Packets, i.e. the number of routing packets.
3.3.4 MAC Load
MAC load means the average number of MAC messages generated
for the successful delivery of each data packet to the destination. Hence,
lower MAC load signifies better congestion control algorithm. The unit for
MAC load is packets.
3.3.5 Dropped Packets
The data packets that fail to reach sink due to congestion during
transmission are dropped packets. In a better congestion control algorithm the
count of dropped packets should be significantly low. The unit for this metric
is Packets per Second.
3.3.6 End to End Delay
End to End Delay (EED) is the cumulative delay that might
arise as a result of buffering during discovery of routes over sensor
network, queuing at interfaces of the sensor nodes, delays in retransmission at
MAC, and the time taken for propagation and transfer over the sensor field.
58
Evidently a better algorithm will deliver the packets with minimum delay.
The unit for EED is milliseconds.
EED= (rn, sn)N
n=1
(3.1)
where
-the time that data packet n was sent
-the time that data packet n was received
-the total number of data packets received.
3.4 PERFORMANCE ANALYSIS OF TRANSPORT
PROTOCOLS
TCP, UDP and SCTP are well suited for efficient streaming
communication over unreliable internet but they need to be improved for
better performance over a typical wireless sensor network scenario. A typical
wireless sensor network is highly unstable as it is error-prone due to various
reasons such as interference of radio signal, radio channel contention, and
survival rate of nodes (Yao-Nan Lien 2009).This error rate is increased
significantly in a multi-hop network due to channel contention. Further, in a
sensor network error rate is much higher and bandwidth is smaller than that of
fixed networks. As a consequence, running conventional TCP, UDP or SCTP
protocol on a wireless sensor network will potentially suffer from severe
performance degradation (Zhaojuan Yue et al 2012).
It is obvious that the capabilities of wireless sensor nodes are much
less than that of their fixed network counterparts, due to various reasons
(Jang-Ping Sheu et al 2009). The complexity in implementing a standard TCP
or SCTP protocol inside the tiny sensor nodes further degrades the
59
performance of wireless nodes. However, the capabilities of the modern
sensor nodes have improved so much to accommodate a fully functional TCP
like protocol stack inside them. Protocol DCCP is having some interesting
properties, which makes it possible to use it in an error-prone sensor network
scenario. To evaluate the performance of DCCP, when implemented over a
congested WSN, it is necessary to conduct experiments under various
environmental conditions.
UDP is a simple open systems interconnection transport layer
protocol for client-server network applications based on Internet protocol and
was introduced in 1980 as a main alternative to TCP. UDP is an unreliable
protocol as it does not include any congestion control mechanism. The
messages, to be sent by the sender, are split in to datagrams and these
datagrams are sent as packets on the network layer, without any buffer
support on both sending and receiving sides. UDP is mainly for real-time
performance oriented applications such as video-conferencing and computer
games. To achieve higher performance, as preferred by the applications,
dropping of individual packets without any retries and reception of packets in
a different order than they were sent are permitted.
So, evaluating these classical protocols on wireless sensor networks
may provide an opportunity to understand and estimate their performance in
wireless sensor networks. An in-depth analysis, based on the above study,
may help us to include the necessary modifications and improvements so as to
accommodate those protocols for wireless sensor networks. More experiments
and evaluations are needed to understand the behavior of these protocols
under congested sensor network scenario which may lead to the selection of a
better congestion control algorithm for wireless sensor networking.
60
3.4.1 Transmission Control Protocol
A basic strategy for communication among dissimilar networks
called as TCP. The evolution that followed provides a reliable and ordered
delivery of a data among the communicating nodes. Internet protocol suite
comprises two core protocols viz. TCP and IP and commonly referred to as
TCP/IP. In the event of data transmission between two computers, TCP,
staying between an application program and the Internet protocol, provides
reliable and ordered delivery of a stream of bytes from a program on one
computer to another program on another computer (Bennett et al 1999). That
is, when an application program desires to send a large chunk of data across
the internet using IP, instead of breaking the data into IP-sized pieces and
issuing a series of IP requests, the software can issue a single request to TCP
and let TCP to handle the IP details.
TCP is a byte-stream protocol as its flow control and
acknowledgement are based on byte number rather than packet number.
However, the smallest unit of data transmitted over the internet is a data
segment or packet and each packet is identified by a data octet number. When
a destination receives a data segment, it acknowledges the receipt of the
segment by issuing an ACK with the next expected data octet number. The
time elapsed between moment a data segment is sent and the moment an ACK
for that segment is received is known as the RTT of the communication
between the source and the destination, which is the sum of the propagation,
transmission, queuing, and processing delays at each hop of the
communication, along with the time taken to process a received segment and
generate an ACK for the segment at the destination.
The flow control mechanism used by TCP is a credit allocation
scheme. To avoid overwhelming its buffer space, a destination advertises to
the associated source the size of a window, called as advertised window,
61
which indicates the number of data bytes, beyond the acknowledged data, the
source can send to the destination. This information is included in the header
of each TCP (data or control) segment sent to the source. Suppose that based
on the ACKs received, a source knows that ‘Byte ’ is the last data byte
received by the destination. The source can send data up to Byte + ,
where W is the size of the advertised window. The scenario of the source’s
sequence number space is exhibited in Figure 3.2.
Figure 3.2 An illustration of the source sequence number space and advertised window in TCP
3.4.2 Congestion Control Operations of TCP
To achieve good performance, it is necessary to control network
congestion so that the number of packets lost within the internet is well below
the level at which the network performance drops significantly. Various
congestion control measures (Stefan Savage et al 1999) have been
implemented in TCP to limit the sending rate of data entering the internet by
regulating the size of the congestion window cwnd, and the number of
unacknowledged segments permitted over the link. These measures include
slow start, congestion avoidance, fast retransmit, and fast recovery. When a
new connection is established, TCP initializes the cwnd size to 1. In slow
start, the value of cwnd is incremented by one each time an ACK is received
until it reaches the slow start threshold, ssthresh.
Sent but Unacknowledged Not yet Sent
Advertised Window
Sequence Numberx x + W
62
TCP uses segment loss as an indicator of network congestion. To
characterize a segment as being lost in transit, a source has to wait long
enough without receiving an ACK for the segment. Therefore, a
retransmission timer is associated with each transmitted segment and a timer
timeout signals a segment loss. The Retransmission Timeout Period (RTO) is
determined by the sum of the smoothed exponentially weighted moving
average and a multiple of the mean deviation of RTT (Leung et al 2007).
When a timeout occurs, ssthresh is set to half of the amount of outstanding
data sent to the network. The slow start process is performed starting with
cwnd set to one and changes the size of it using AIMD technique, until it
reaches ssthresh. The congestion avoidance phase is then carried out where
cwnd is increased by one for each RTT.
When the data octet number of an arriving segment is greater than
the expected one, the destination finds it as a sequence hole, i.e. a gap in the
sequence number space. Then the receiver immediately sends out a duplicate
ACK, i.e., an ACK with the next expected data octet number in the
cumulative acknowledgement field, to the source, instead of the ACK for the
segment received with sequence hole. If the communication channel is an
in-order channel, the reception of a duplicate ACK implies the loss of a
segment. When the source receives three duplicate ACKs, fast retransmit is
triggered such that the inferred loss segment is retransmitted before the
expiration of the retransmission timeout.
Fast recovery works as a companion of fast retransmit. A fast
retransmission suggests the presence of mild network congestion. To handle
this, ssthresh is set to half of the amount of outstanding data sent to the
network. Since the reception of a duplicate ACK indicates the departure of a
segment from the network, cwnd is set to the sum of ssthresh and the number
63
of duplicate ACKs received. When an ACK for a new segment arrives, cwnd
is reset to ssthresh and then congestion avoidance takes place.
Packet reordering refers to the network behavior where the relative
order of some packets in the same flow is altered when these packets are
transported in the network. In other words, the receiving order of a flow of
packets or segments differs from its sending order. The presence of persistent
and substantial packet reordering violates the in-order or near in-order
channel assumption made in the design principles of some traffic control
mechanisms in TCP. This can result in a substantial degradation in application
throughput and network performance (Laor and Gendel 2002).
Modern TCP implementations also include congestion control
mechanisms that adapt the source transmission behaviour to network
conditions by dynamically computing the congestion window size. The goal
of TCP congestion control is to increase the congestion window size, if there
is additional bandwidth available on the network, and decrease the congestion
window size upon congestion. It is widely agreed that the congestion control
schemes in TCP provide stability for the “best effort” internet. These
mechanisms increase network utilization, prevent starvation of flows, and
ensure inter-protocol fairness (Floyd and Fall 1999).
With TCP as the benchmark, a transport mechanism in WSN
should have basic functionalities such as reliable transport of data, better
congestion control means, reasonable rate-control and acceptable fairness
(Xiaohua Luo 2004).
3.4.3 User Datagram Protocol
The UDP is another protocol with TCP/IP suit which can send
messages, or datagrams in this protocol, to other nodes on IP network without
64
requiring prior communications to set up special transmission channels or
data paths.
UDP does not guarantee reliability or ordering in the way that TCP
does. Datagrams may arrive out of order, appear duplicated, or go missing
without notice. Avoiding the overhead of checking whether every packet
actually arrived makes UDP faster and more efficient, at least for applications
that do not need guaranteed delivery. Time-sensitive applications often use
UDP because dropped packets are preferable to delayed packets. UDP's
stateless nature is also useful for servers that answer small queries from huge
numbers of clients. Unlike TCP, UDP supports packet broadcast i.e. sending
to all on local network and multicasting i.e. send to all subscribers.
UDP assumes that error checking and correction is either not
necessary or performed in the application, thus avoiding the overhead of such
processing at the network interface level. Due to this, the arrival of datagrams
may not be in the same order in which they were transmitted and some of the
transmitted datagrams may not reach the receiver and hence, lost during
transmission.
The QoS is further deteriorated by data duplication and data loss.
UDP is more appropriate for applications where time is precious than data
loss and hence, seldom suitable for real-time applications.
3.4.4 Stream Control Transmission Protocol
In SCTP the transmission of a message is in the form a stream
instead of individual data packets and hence, considered as a single operation.
Similarly the reception of the exact message is also considered as a single
operation (Boussen et al 2009, Maria-Dolores Cano 2011). “Multi-homing”
65
and “Multi-streaming” are the two special features of SCTP and a connection
between two endpoints in this context is called an “association”.
Multi-homing is defined as the ability of an association to support
multiple IP addresses or interfaces at a given end point. Use of more than one
address permits re-routing of packets in the event of failure and also provide
an alternate path for retransmissions, thus resulting in greater survivability of
the session.
Multi-streaming represents a sequence of messages, either long or
short, within a single association and different from multiple streams. The
messages include control flags for segmentation and reassembly. Stream
Identifiers and Stream Sequence numbers are included in the data packet to
allow sequencing of messages on a per-stream basis which eliminates the
unnecessary head-of-line blocking between independent streams of messages,
in case of loss in any of the streams. In addition SCTP provides mechanism
for designating order-of-arrival delivery as opposed to ordered delivery.
3.4.5 Datagram Congestion Control Protocol
With UDP as the base, DCCP is developed for effective and
efficient handling of congestion, resulting in more reliable transmission of
datagrams or packets. It is highly promising that DCCP will become the
defacto standard for multimedia rich content delivery over IP-based networks
(Stanimir Statev et al 2008). The main objective of DCCP is to extend support
for implementing different congestion control schemas out of which the most
suitable one may be selected by the applications, particularly multimedia
streams, so as to provide efficient congestion control.
66
Hence, according to the type of data being transmitted a schema
will be selected to assure a better flow of packets. A mechanism, known as
CCID, is implemented in DCCP, enabling it to assign separate CCID for each
direction of data flow. The nature of congestion is defined by CCID and the
source and destination select appropriate mechanism to handle this congestion
by feature negotiation (Kohler et al 2006), a method that selects the best
suited algorithm for the present scenario. DCCP congestion control structure
is so designed that the addition of new congestion control algorithms or the
deletion/modification of existing algorithms takes place, regardless of the core
of the protocol. Presently DCCP-TCP-like and DCCP-TFRC are two such
standard mechanisms.
3.4.6 DCCP-TCP-like Congestion Control
The DCCP-TCP-like Congestion Control mechanism implements
an algorithm that controls the congestion through tracking a transmission
window, and regulating the transmit rate similarly to that of TCP and
designated as CCID 2.
CCID 2 takes the advantage of available bandwidth in a rapidly
changing environment and is suitable for senders who can adapt to the abrupt
changes in congestion window, typical to that of TCP’s AIMD congestion
control (Floyd and Kohler 2006). CCID 2 is also appropriate for DCCP flows,
that would like to receive as much bandwidth as possible over long term and
consistent with the use of end-to-end congestion control and tolerates large
sending rate variations characteristic of AIMD congestion control, including
halving of the congestion window in response to a congestion event. Hence,
CCID 2 is most suitable for applications that simply need to transfer as much
data as possible over a short period of time.
67
3.4.7 DCCP-TFRC Congestion Control
Congestion control is implemented in DCCP-TFRC by tracking the
packet loss rate and varying the transmission rate in a smoother manner using
AIMD, and this technique of congestion control is designated as CCID 3.
DCCP-TFRC is a receiver-based congestion control mechanism
that provides a TCP-friendly sending rate while minimizing the abrupt-rate-
change characteristic of TCP or TCP-like congestion control. Upon receiving
a loss event rate sent by the receiver, the sender sets its allowed sending rate
appropriately (Floyd et al 2006). CCID 3's TFRC congestion control is most
suitable for flows that would prefer to minimize abrupt changes in the sending
rate, including streaming media applications with small or moderate receiver
buffering before playback.
3.5 PERFORMANCE ANALYSIS
Sensor networks with protocols TCP, UDP, SCTP, DCCP-TCP-like
and DCCP-TFRC have been simulated with different data reporting intervals
and the results obtained are plotted with respect to the data reporting intervals
and metrics concerned. The individual performances of all the five protocols
with respect to the desired metrics are given in Tables 3.3 through Table 3.7.
The performance of each protocol is analyzed in this section along with the
comparison of the performances of other protocols.
Table 3.3 shows that the performance of TCP for different metrics
taken for consideration. It is observed from the table that TCP does not
perform well in terms of EED delay. The average EED delay obtained by
TCP is 370.39 which are very higher when compared with other protocols
taken for analysis. TCP provides second worst results in terms of Average
68
Routing Load, Average MAC Load and Average Dropped Packets, with the
value of 56.49, 118.05 and 56089.80 respectively.
Table 3.3 Performance of TCP
Interval(seconds)
EEDDelay(ms)
Routing Load (pkts)
MacLoad (pkts)
Dropped Packets
(pkts /sec)
Throughput(bytes/sec)
Consumed Energy (Joules)
1 249.01 28.32 68.27 65052 63.19 1.55
2 275.87 29.37 72.74 64538 62.09 1.58
5 114.08 56.72 120.09 53616 22.71 1.39
10 583.10 73.64 143.74 49793 14.59 1.34
20 629.88 94.40 185.42 47450 9.88 1.31
Average 370.39 56.49 118.05 56090 34.49 1.43
The performance of TCP is found to be poor in terms of average
energy consumption with the value of 1.43 Joules. TCP provides second best
result for throughput next to UDP when Average throughput is considered.
Thus, on the whole except for average throughput, TCP provides poor results