Upload
vuhuong
View
225
Download
2
Embed Size (px)
Citation preview
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
with respect to the metrics considered.
Table 3.4 Performance of UDP
Interval(seconds)
EEDDelay(ms)
Routing Load (pkts)
MacLoad (pkts)
Dropped Packets
(pkts /sec)
Throughput(bytes/sec)
Consumed Energy (Joules)
1 34.47 3.56 14.87 12323 105.7 1.652 34.89 5.09 20.42 8025 52.24 1.485 16.99 4.14 16.12 3301 21.56 1.2010 27.19 11.01 40.96 7654 10.52 1.2620 32.17 19.51 68.12 9263 5.43 1.24
Average 29.14 8.66 32.10 8113 39.09 1.37
69
It is noticed from the Table 3.4 that UDP provides third best result
in terms of EED delay next to DCCP-TCP-like and DCCP-TFRC approach
with the delay of 29.14 ms. UDP also provides third best results in terms of
Average Routing Load, Average MAC Load and Average Dropped Packets,
with the value of 8.66, 32.10 and 8113.20 respectively. UDP provides
moderate results in terms of average consumed battery energy with the value
of 1.37 Joules. UDP outperforms other protocols with highest throughput.
Thus, on the whole UDP provides moderate results with all the metrics taken
for consideration.
Table 3.5 shows the overall performance of the SCTP. SCTP does
not provide significant EED delay and the delay is very high, 188.72 ms. The
average routing load of SCTP is 82 and it is the highest routing load when
compared with other protocols. The average MAC load obtained is 164.38
which is also higher than other protocols. The packets dropped by the SCTP is
very large than the other protocols.
Table 3.5 Performance of SCTP
Interval(seconds)
EEDDelay(ms)
Routing Load (pkts)
MacLoad (pkts)
Dropped Packets
(pkts /sec)
Throughput(bytes/sec)
Consumed Energy (Joules)
1 186.17 34.21 79.32 92022 29.58 1.54
2 188.42 61.03 124.16 91193 14.89 1.44
5 312.48 84.41 171.60 74672 6.90 1.38
10 30.95 109.72 207.37 89088 4.90 1.38
20 222.57 120.62 224.44 70430 2.77 1.34
Average 188.72 82.00 161.38 83481 11.81 1.42
70
In terms of Average consumed energy, SCTP does not provide
significant results as it consumes higher energy next to TCP. Average
throughput by the SCTP is also very less when compared with other
algorithms. Average Through put of DCCP-TCP-like is 13.24 kbps which is
the better than SCTP. From the foregoing discussion it may be observed that
SCTP fails in all aspects with respect to WSN, and hence not a suitable
protocol for WSN.
Table 3.6 Performance of DCCP-TCP-like
Interval(seconds)
EEDDelay(ms)
Routing Load (pkts)
MacLoad (pkts)
Dropped Packets
(pkts /sec)
Throughput(bytes/sec)
Consumed Energy (Joules)
1 26.12 4.45 17.32 9369 19.05 1.26
2 11.61 3.75 14.90 3633 17.39 1.21
5 9.73 3.58 14.61 2147 13.92 1.22
10 11.46 1.31 17.24 2990 10.46 1.20
20 21.64 7.78 28.77 7700 5.38 1.26
Average 16.11 4.77 18.57 5168 13.24 1.23
It is observed from the Table 3.6 that the average energy consumed
by DCCP-TCP-like is 1.23 Joules which is the second best result, and next to
DCCP-TFRC approach. The routing load is also very less for DCCP-TCP-
like. It is the second least value next to DCCP-TFRC. When the MAC load is
considered DCCP-TCP-like provides a relatively lower value, 18.57. The
packets dropped by the DCCP-TCP-like approach is also very less when
compared with the protocols TCP, UDP and SCTP.
71
Table 3.7 Performance of DCCP-TFRC
Interval(seconds)
EEDDelay(ms)
Routing Load (pkts)
MacLoad (pkts)
Dropped Packets
(pkts /sec)
Throughput(bytes/sec)
Consumed Energy (Joules)
1 30.97 4.13 16.46 7113 21.40 1.22
2 15.63 3.74 15.03 3340 19.30 1.35
5 9.86 3.59 14.39 2544 15.72 1.30
10 11.14 3.90 15.60 2316 11.76 1.23
20 16.62 7.40 28.40 6117 5.79 1.25
Average 16.84 4.55 17.98 4286 14.79 1.27
When EED delay is considered, DCCP-TCP-like produces the least
delay among all the five protocols with 16.11 ms. Thus DCCP-TCP-like
approach provides significant results with all the metrics found to be next to
DCCP-TFRC Table 3.7 shows the overall performance of the DCCP-TFRC
with respect to performance metrics taken for consideration. It is observed
from the Table that the DCCP-TFRC outperforms all the other protocols
taken for consideration and provides a fairly acceptable result along with
DCCP-TCP-like.
3.5.1 Throughput
Figure 3.3 show the throughputs of all the five protocols against
different data reporting intervals. Upon considering the individual
performances, it is noticed that during low data reporting intervals the
throughputs are better for all protocols, comparing their corresponding high
data reporting interval response.
72
Figure 3.3 Data reporting interval Vs throughput of all protocols
As TCP is reliable and byte oriented, the throughput is relatively
better as it assures the delivery of all the data bytes. Though SCTP is also
reliable, it is stream oriented and hence, even a loss of single byte in a stream
necessitates the retransmission of entire stream again, bringing down the
throughput. Further, in SCTP, the life time of the data to be transmitted is
specified by the application and hence, in case if the life time expires, the data
will be discarded even if it is not sent, which deteriorates throughput. Unlike
TCP and SCTP which use dedicated paths, UDP is permitted to send the data
through all the available paths which increases the probability of the data
delivery and so the throughput.
It is found that the throughputs of all the protocols converge as the
data reporting time increases. It is also observed that when the data reporting
interval is too low UDP outplays other protocols. As the data reporting
interval increases the performance of TCP improves and provides best
throughput at high data reporting intervals among all protocols, which is
closely followed by UDP. Figure 3.4 shows the average throughput of the
0
20
40
60
80
100
120
1 2 5 10 20
Thro
ughp
ut(K
bps)
Data Reporting Interval (sec)
Data Reporting Interval Vs. Throughput
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
73
protocols and it may be concluded that the performance of TCP protocol
based networks, baring low data interval periods, is the best and UDP
dominates during low data reporting intervals due to highest delivery rate
during that period.
Figure 3.4 Average throughput of all protocols
3.5.2 Energy Consumption
The amount of energy consumed in Joules by all five protocols over
the data reporting intervals are given in Figure 3.5 and the average of energy
consumed by the protocols is given in Figure 3.6. At lower data reporting
intervals, the reporting is more frequent which results in higher energy
consumption for all the protocols as shown in Figure 3.5. It is found that
UDP consumes maximum energy during low data reporting intervals in view
of higher throughput. The energy consumption falls significantly on moving
towards higher data reporting intervals for UDP, resulting in moderate
average energy consumption over the entire period with respect to UDP as
shown in Figure 3.6.
34.4939.09
11.81 13.2414.79
05
1015202530354045
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
Thr
ough
put(
Kbp
s)
Protocols
Average Throughput
74
As TCP and SCTP are reliable protocols, it is necessary for them to
retransmit the data when data is discarded, reordered, duplicated or corrupted.
Due to this it is obvious that the energy requirement is higher for them in
view of additional overheads to assure proper delivery of data, as shown in
Figures 3.5 and 3.6.
Figure 3.5 Data reporting interval Vs energy consumed by all protocols
With respect to the variants of DCCP, the energy consumption is
relatively lesser than other three protocols, as the retransmission is permitted
only for control packets and not for data packets in those protocols. Among
the protocols DCCP-TCP-like and DCCP-TFRC, protocol DCCP-TCP-like
found to consume lesser energy over the entire time period considered due to
its abrupt nature i.e. the window size is reduced suddenly on sensing
congestion, as observed from Figures 3.5 and 3.6. The smooth transmission
behavior of DCCP-TFRC, on sensing congestion, forces it to consume bit
higher energy than that of DCCP-TCP-like.
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1 2 5 10 20
Ene
rgy
Con
sum
ed(J
oule
s)
Data Reporting Interval (sec)
Data Reporting Interval Vs. Energy Consumed
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
75
Figure 3.6 The average energy consumed by all protocols
3.5.3 Routing Load
The amount of routing load over different data reporting intervals
for the five protocols are shown Figure 3.7. With respect to the protocols
SCTP and TCP, it is found from the Figure 3.8, the routing load is
prohibitively higher in view of their additional overheads to assure reliable
transmission. With respect to other three protocols, as there is no
retransmission of data the required routing load falls significantly. It is
observed that DCCP-TFRC and DCCP-TCP-like protocols result in almost
equal routing load over the entire time interval and also the lowest among all
the protocols. UDP protocol closely follows DCCP based protocols at low
reporting intervals and marginally increases with reporting time.
1.43
1.37
1.42
1.23
1.27
1.1
1.15
1.2
1.25
1.3
1.35
1.4
1.45
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
Ener
gyC
onsu
med
(Jou
les)
Protocols
Average Energy Consumed
76
Figure 3.7 Data reporting interval Vs. routing load of all protocols
Figure 3.8 Average routing load of all protocols
The average routing load for all five protocols is shown in
Figure 3.8 and it is clear from it that DCCP based protocols provide best
performance among all the protocols considered.
3.5.4 MAC Load
Comparing Figure 3.7 with Figures 3.9 and 3.8 with 3.10 it may be
easily concluded that the performance of MAC load is similar to that of
Routing load for all the five protocols.
0
20
40
60
80
100
120
140
1 2 5 10 20
Rou
ting
Loa
d(p
kts)
Data Reporting Interval (sec)
Data Reporting Interval Vs. Routing Load
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
56.49
8.66
82
4.77 4.55
0102030405060708090
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
Rou
ting
Loa
d(p
kts)
Protocols
Average Routing Load
77
Figure 3.9 Data reporting interval Vs MAC Load of all protocols
Hence, from the discussions given in section 3.5.3, it may be
arrived that the performances of the networks, based on DCCP are better than
all other protocols with respect to MAC load also.
Figure 3.10 The average MAC load of all protocols
0
50
100
150
200
250
1 2 5 10 20
MA
CLo
ad(p
kts)
Data Reporting Interval (sec)
Data Reporting Interval Vs. MAC Load
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
118.05
32.1
161.38
18.57 17.98
0
20
40
60
80
100
120
140
160
180
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
MA
CLo
ad(p
kts)
Protocols
Average MAC Load
78
3.5.5 Dropped Packets
Figure 3.1 1 displays the number of dropped packets during
different data reporting intervals for the five protocols considered in this
work.
Figure 3.11 Data reporting interval vs. dropped packets by all protocols
TCP and SCTP protocols transmit data from a source to a
destination only through a dedicated path and hence, when congestion occurs
the probability of data loss is high. The life time specific data packets in
SCTP increase the count of dropped packets further, due to which the amount
of dropped packets in SCTP is always high. UDP transmits data through all
the available paths and hence, if data is lost in one path due to congestion or
any other reason, the same data which is travelling over other paths may reach
the destination successfully, thus reducing the amount of dropped packets.
On the other hand DCCP variants, after establishing a connection
between a sender and a receiver after negotiation, start data transmission and
in case of congestion they reset the connection and reestablish it. Due to this
0100002000030000400005000060000700008000090000
100000
1 2 5 10 20
Dro
pped
Pack
ets(
pkts
/sec
)
Data Reporting Interval (sec)
Data Reporting Interval Vs. Dropped Packets
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
79
in DCCP protocol based networks the amount of data loss is minimized as
shown in Figures 3.11 and 3.12. Upon considering the average loss over the
data reporting interval as given in Figure 3.12, it is found that the data loss
with respect to DCCP based protocols is the least.
Figure 3.12 Average dropped packets by all protocols
3.5.6 End-to-End Delay
From Figure 3.13 it is obvious that the EED is higher with respect
to TCP and SCTP as the average amount of data loss is prohibitively higher
than other three protocols as shown in Figure 3.12. Though the average data
loss is higher in case of the TCP than that of SCTP, former takes relatively
longer time to deliver data as given in Figure 3.13 for all the data reporting
intervals considered. The reason is that, TCP is byte oriented protocol and the
delivery of each byte is to be assured by it where as SCTP is stream oriented
protocol and it is related to the delivery stream of bytes rather than individual
byte and hence, the latter involves relatively lesser overheads.
56090
8113
83481
5168 4286
0100002000030000400005000060000700008000090000
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
Dro
pped
Pack
ets(
pkts
/sec
)
Protocols
Average Dropped Packets
80
Figure 3.13 Data reporting interval Vs. end-to-end delay of all protocols
With respect to the remaining three protocols, EED is relatively
very low and constant over the reporting intervals considered. It may further
be noticed that DCCP-TCP-like and DCCP-TFRC protocols based networks
exhibit almost same delay time where as that of UDP based networks is
marginally higher. These facts are evident on considering average EED as
given Figure 3.14.
Figure 3.14 Average end to end delay of all protocols
0
100
200
300
400
500
600
700
1 2 5 10 20
End-
to-E
ndD
elay
(ms)
Data Reporting Interval (sec)
Data Reporting Interval Vs. End-to-End Delay
TCP
UDP
SCTP
DCCP-TCP-like
DCCP-TFRC
370.39
29.14
188.72
16.11 16.84
0
50
100
150
200
250
300
350
400
TCP UDP SCTP DCCP-TCP-like DCCP-TFRC
End
-to-
End
Del
ay(m
s)
Protocols
Average End-to-End Delay
81
3.6 RESULT ANALYSIS
The consolidated performance of WSN based on the transport
protocols TCP, UDP, SCTP and DCCP-TCP-like and DCCP-TFRC is given
in Table 3.8.
Table 3.8 Average performance of protocols TCP, UDP, SCTP and DCCP variants
S.No. Metric TCP UDP SCTP DCCP-TCP-like
DCCP-TFRC
1 Throughput(Kbps) 34.49 39.09 11.81 13.24 14.79
2 Energy (Joules) 1.43 1.37 1.42 1.23 1.27
3 Routing Load (pkts) 56.49 8.66 82.00 4.77 4.55
4 MAC Load (pkts) 118.05 32.10 161.38 18.57 17.98
5 EED Delay (sec) 370.39 29.14 188.72 16.11 16.84
6Dropped Packets (pkts/sec)
56090 8113 83481 5168 4286
As TCP is a reliable protocol, which ensures in-order delivery of
packets with congestion control, the overheads involved are high, which
results in underutilization of resources which is reflected as poor performance
indices, as shown in Table 3.8. On the other hand, it is found that UDP is far
better than TCP, but at the cost of reliability and congestion. As SCTP too is a
reliable protocol, it also attracts more overheads as given in Table 3.8. DCCP
includes congestion control mechanisms as in the case of TCP and unreliable
transmission like UDP and hence, the performance of DCCP variants found to
be the best, bearing the transmission loss, which is not a main criterion in
WSNs, as only the recent information are preferred than older ones in WSN.
82
3.7 SUMMARY
A brief overview of the simulation scenario over which all
proposed algorithms in this work are implemented to analyze their
performance, is presented in this chapter. The specifications of different
parameters of the nodes and sensor field are also given. The standard metrics
prescribed to validate the performance of the networks, with different
algorithms are also discussed.
The congestion control behavior of the wireless sensor networks
based on five protocols TCP, SCTP, UDP, DCCP-TFRC, DCCP-TCP-like
with respect to six metrics viz. throughput, pocket-loss or dropped packets,
routing load, MAC load and EED have been analyzed in this chapter. To
analyze the congestion control performance of the networks based on the
above protocols, the scenario given earlier in this chapter has been
successfully simulated under the package NS2 for a range of data reporting
intervals and the results thus arrived have been tabulated and plotted. The
performances of the networks based on the metrics considered have been
analyzed in detail.
The throughputs of TCP and UDP protocols based networks are
relatively higher at low data reporting intervals where as the throughputs are
almost equal for all the five protocols at high data reporting intervals. Hence,
it may be concluded that DCCP-TFRC and DCCP-TCP-like protocols based
networks behave almost similar to other protocols at high data reporting
intervals. It may also be observed that the average energy consumption is low
with respect to DCCP based networks despite the initial fluctuations and that
of TCP and SCTP are much higher. The energy consumption is high for UDP
83
based networks at low reporting intervals and almost equal to that of DCCP
based networks and hence, it may be arrived that the DCCP networks, on
average, consume energy lesser than other protocols. With respect to the
remaining metrics routing load, MAC load, dropped packets and EED it may
be observed that the performance of DCCP based networks are far better that
TCP and SCTP based networks and just above UDP based networks. Hence,
from the arrived results it is concluded that DCCP protocol may be the best
suited protocol among the protocols considered for wireless sensor networks.