Energy Consumption of TCP Reno, Newreno and SACK in Multi-Hop Wireless Network Harkirat Singh & Suresh Singh.

Energy Consumption of TCP Reno, Newreno and SACK in Multi-Hop Wireless Network

Harkirat Singh &

Suresh Singh

Outline Motivation TCP Mechanism Energy Model Experiment Methodology Experiment Results Conclusion

Motivation Wireless devices need to be

Reliable Light Weight

Wireless links are error prone, low bandwidth etc.

TCP connection suffers long idle time hence

low throughput

How is Power consumed in a wireless node?

Radio States : Transmit, receive, idle, sleep

Idle / Sleep

Power (Idle) = 780mW

Power (Sleep) = 50mW

Recv Xmt

Power (Xmt) = 1478mW

Data

Ack

Power (Recv) = 900mW

Lucent 802.11 Silver (11 Mbps) WaveLAN DSSS PC Card Characteristics [INFOCOM’01]

TCP Mechanism TCP is a sliding window protocol with built in

self-clocking and congestion control algorithm• Slow start Congestion avoidance• Fast retransmit• Fast recovery

TCP Tahoe implements first three

TCP Reno, Newreno and SACK have all four

Slow start Slow start is used during initial phase of a connection or after retransmission timeout (Probing the network) It is also known as additive increase and multiplicative decrease

Sender

Receiver

cwnd:1 cwnd:2 cwnd:4 cwnd:8

Fast retransmit and recovery TCP receiver generates ack for next expected

packet In the event of packet loss or reordering, receiver

Acks last in-sequence pkt received TCP sender retransmits first unacknowledged

packet after 3 dup_acks without waiting for retransmit timer to go off

ssthresh = min (cwnd, rcv advertised window) / 2 Send missing pkt and set cwnd += 3 Inflate cwnd till retransmitted pkt is acked Deflate the window, enter Congestion Avoidance

Congestion Avoidance When cwnd > ssthresh TCP invokes

Congestion Avoidance

cwnd += 1/cwnd (for each ack) In other words cwnd is incremented

(cwnd++) by one per round trip time It is conservative approach to increase

cwnd as name suggests

When congestion is detected (by timeout), TCP slows down and invokes slow start

Evolution of TCP window

RTT RTT

W

W+1

2 W

2

4

8

1

RTT

Fast retransmit and recovery

Congestion avoidance

Slow start

Time

Con

gest

ion

Win

dow

Evolution of cwnd

Time

Outs

tand

ing D

ata

TCP Newreno TCP Reno is optimized for single packet loss in a

window, multiple pkt loss degrades the performance

TCP Newreno enhances the performance in the event of multiple pkt drop without having SACK

Introduces new variable Partial ACK• When fast retransmit is invoked record the

highest sequence number transmitted as Recover• When all of the data up to and including Recover

is acknowledged TCP exits fast recovery Avoids invocation of Fast retransmit in quick

succession

Sender Receiver

0 .. 61 14

cwnd : 8

7 .. 14 7 .. 13

0 .. 131

cwnd : 15

15 .. 28 15 .. 28

New round

14 14, 29 .. 34

14

14 dup Acks

New round

cwnd : 10

29 .. 34

cwnd : 21

0 .. 281

cwnd : 7

Receiver generates Ack 29, sender exitsFast recovery and adjust “inflated” cwnd and enters Congestion avoidance

TCP SACK SACK Data structure

• Recover and Partial ack as Newreno• Receiver informs non-contiguous data• Receiver can reflects max of three SACK

blocks• Sender maintains a queue of segments that

have been transmitted but not yet acknowledged, Scoreboard

SACK is invoked in the event of three dup_acks

Sender can judiciously send new packet or retransmit packet to fill hole at receiver

TCP SACK Data Structuresstruct tcpcb { …

struct sackhole *snd_holes; …

tcp_seq start

tcp_seq end

next

dups

rxmit

tcp_seq start

tcp_seq end

next

dups

rxmit

tcp_seq start

tcp_seq end

next

dups

rxmit

…

SACK Example

1 2 3 4 5 6 1

4

6

2

ACK 1 SACK [2]

1 3 4 5 6 2 3

ACK 1 SACK [3,2]

1 4 5 6 2 3 5

ACK 1 SACK [5,3,2]

1 4 6 HOLES AT RCVR

Sender’s queue Receiver’s queue

Evolution of ACK received by TCP-SAC Sender  

Time

Sequen

ce N

um

ber

3 dup_ack

TCP Protocols Summary

Partial ACK

Recv holes details

Modified Recv

RENO NO NO NO

NEWRENO YES NO NO

SACK YES YES YES

Outline Motivation TCP Mechanism Energy Model Experiment Methodology Experiment Results Conclusion

Energy consumption of a node

Idle Current Consumption Pidle

Idle Period

Packet Reception + Processing Packet Processing + Transmission

Time

Cu

rre

nt

PRX

PTX

Energy Model Total energy (E) can be represented as

PTX is energy spent for transmission tTX is time spent in transmission tRX is negligible so can be eliminated

Assume average connection throughput is bytes/sec and the transmission speed is r bytes/sec we can write

TxTxTxtotalidle tPttPE

)()/()/( idleTxidle PPrBPBE

Goals Awake node during ideal time consume

unnecessary power

Power off nodes during idle period this gives lower bound of Total Energy consumption though not realistic call it Idealized Energy

Alternatively during idle period node is asleep and in the event of a pkt node is awoken up by radio

Goals contd.’ Investigate the Energy consumption of TCP

variants (Total Energy vis-à-vis Idealized Energy)

TCP connection characteristic in wireless revisited Low bandwidth connection Higher BER Mobility These leads to longer Idle time

Hence TCP sender can sleep!!

Evolution of TCP Sequence

Idle connection

Time

Seq

uen

ce

Nu

mb

er

Outline Motivation TCP Mechanism Energy Model Experiment Methodology Experiment Results Conclusion

Test Bed Three hop wireless ad hoc network

Each laptop equipped with Lucent 11 Mbps WaveLAN card Running FreeBSD 4.3

SACK is implemented based on RFC 2018

Dummynet used for packet loss and delay

Energy measurement at sender using HP 34401A multimeter and VeePro software

Energy Measurement Two multimeters simultaneously used for

measuring Radio and Total Node Power

Multimeter takes current measurement with a granularity of 1 millisecond

Multimeter dumps data to different laptop

Integration of current * voltage over connection time gives total Energy

Workload, Factors, and Metrics TTCP used as a constant workload generator - 5 MB

Error : 1%, 5% and 10%

RTT : 15, 40, 70, 100 and 130 msec

Reordering : 1% and 5%

Burst Error : 85% for 1 sec every 12 sec

MTU 512 and 1500

A typical run ..

TCP SENDER

RECEIVER

SONY WITH MULTIMETER (TAKES1000 SAMPLINGS PER SECOND)

Start multimeter

Stop

Start

TTCP Router generates

Loss and Delay(DUMMYNET)

Start TTCP server

Start Loss+Delay script

Pkt

Pkt

Pkt

Energy Consumed by Node

Idealized Energy

Total Energy

Simultaneous measurement ofEnergy consumed by the radio

Time (msec)

Curr

ent

(mA

)

Metrics

Total Energy/bit ( E ) measured in Joules/bit. This includes the energy consumed while the sender is idle

Idealized Energy/bit ( EI ) measured in Joules/bit. This measure excludes the idle time energy and thus more closely approximates the cost of the various protocols

Goodput in kbps

Outline Motivation TCP Mechanism Energy Model Experiment Methodology Experiment Results Conclusion

Experiment Results – Burst Loss

Parameters Values

Average RTT Burst Packet Loss MTU Size RTS/CTS Protocols

15, 40, 70, 100, 130 msec 85% loss rate for 1 second every 12 seconds 1500 bytes OFF Reno, Newreno, and SACK

Burst loss

Sack-Total

NEWRENO-Total

NEWRENO-IdealSACK-Ideal

Reno

SACK

Goo

dput

(k

bps)

Average RTT (msec) Average RTT (msec)

Energy Goodput

E

nerg

y (J

oule

s *

e-6/

Bit)

Random uniform Loss

Parameters Values

Average RTT Packet Loss MTU Size RTS/CTS Protocols

15, 40, 70, 100, 130 msec 1%, 5%, and 10% 512 and 1500 bytes ON, OFF Reno, Newreno, and SACK

1% Packet Loss

SACK1500

SACK512

RENO512 SACK512

RENO512

SACK1500

NEWRENO1500

Average RTT(msec) Average RTT(msec)

Total Energy Idealized Energy

Tot

al E

nerg

y (J

oule

s *

e-6/

Bit)

Idea

lized

En

ergy

(Jo

ule

s *

e-6/

Bit)

5% Packet Loss

Total Energy Goodput

SACK512

RENO512 & NEWRENO512

SACK1500

RENO1500RENO512 & NEWRENO512

SACK512

SACK1500

NEWRENO1500RENO1500

Average RTT(msec) Average RTT(msec)

Goo

dput

(K

bps)

Tot

al E

nerg

y (J

oule

s *

e-6/

Bit)

TCP Reno, Newreno and SACK (Thruput)

SACK

Newreno

Reno

Time

Th

rup

ut

(bp

s)

Average Thruput: 5% Packet Loss, MTU 1500

10% Packet Loss

Total Energy Idealized Energy

Average RTT(msec) Average RTT(msec)

SACK1500

NEWRENO1500

SACK512

SACK1500

NEWRENO512

Tota

l E

nerg

y (

Jou

les

* e-6

/Bit

)

Idealiz

ed

Energ

y (

Joule

s *

e-6

/Bit

)

Loss Experiment Summary - (mtu 512)

1% Loss 5% Loss 10% Loss

Goodput SACK SACK SACK

Total Energy SACK SACK SACK

Idealized Energy

Reno Newreno Newreno

Packet Reordering

Parameters Values

Average RTT Packet Loss Reorder Packet MTU Size RTS/CTS Protocols

15, 40, 70, 100, 130 msec None 1% and 5% packets reordered 512 and 1500 bytes ON, OFF Reno, Newreno, and SACK

Goodput : Packet Reordering

Average RTT(msec) Average RTT(msec)

Goodpu

t (K

bps)

Goodpu

t (K

bps)

NEWRENONEWRENO

SACK512 & 1500 SACK

1500

1500512

512 1500

512

1% Packet reorder 5% Packet reorder

1% Packet Reordering

Total Energy Idealized Energy

Average RTT(msec) Average RTT(msec)

SACK512

RENO512

NEWRENO512 RENO512

NEWRENO512

SACK512

Tota

l E

nerg

y (

Jou

les

* e-6

/Bit

)

Idealiz

ed

Energ

y (

Joule

s *

e-6

/Bit

)

5% Packet Reordering

Total Energy Idealized Energy

Average RTT(msec) Average RTT(msec)

NEWRENO512

NEWRENO1500

SACK512 & 1500

RENO

1500512

NEWRENO

1500512

SACK512 & 1500

Tota

l E

nerg

y (

Jou

les

* e-6

/Bit

)

Idealiz

ed

Energ

y (

Joule

s *

e-6

/Bit

)

Discussion SACK outperforms in most of the cases (Burst

Loss, Random uniform Loss and Packet Reordering)

Does SACK help YES/NO Higher Goodput at the cost of extra processing

SACK has higher Idealized Energy

Discussion contd.’En

erg

y (

Jou

les

* e-6

/Bit

)

Goodput (Kbps)

E α 1/ζ

Total Energy vs Goodput

• Energy α 1 / Goodput

• Idealized Energy is a factor of Protocol

Discussion contd.’

% Loss

Avera

ge N

um

ber

of

Tim

eouts

Timeouts (Loss case)

SACK1500

RENO512

NEWRENO512

SACK512

• At higher loss all protocols perform alike

• SACK512 leads to lesser timeouts

• SACK - No timeout in reordering case, Reno > Newreno

TCP Energy based on simulation We measured energy using a wireless test-bed

and a real TCP/IP stack (FreeBSD)

Metrics considered were Total Energy, ratio of successful transmission to total number of transmission Total as well as Idealized energy (Processing

energy)

Related Work

Conclusion Awake Energy α 1 / Goodput

Idealized Energy is a factor of Complexity of the Protocol

Channel conditions are important in selection of particular Protocol

SACK is not suitable for nodes with low Idle Energy

SACK has lower Total Energy and Idealized Energy under Packet reordering

Thank You