chapter 3 performance analysis of transport protocols...

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)



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)



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)



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)



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 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


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 Vs. Routing Load

TCP

UDP

SCTP

DCCP-TCP-like

DCCP-TFRC

56.49

8.66

82

4.77 4.55

0102030405060708090


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 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


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 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


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 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


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.

chapter 3 performance analysis of transport protocols...

Documents