Responsive, Energy-Proportional

Computer Networks

Nedeljko Vasić, Dejan Novaković, Satyam Shekhar,

Prateek Bhurat, Marco Canini, and Dejan Kostić

Networked Systems Laboratory

EPFL, Switzerland

Research sponsored by

Networking Energy Consumption

• Internet’s energy consumption is already large

– US network infrastructure requires ~20 TWh/year

– Italy’s ISP Telecom Italia needs ~2 TWh/year

– Datacenter’s networking is 20% of server energy

• More demands will result in further increases

– Video streaming, Video-on-Demand, Cloud computing

• CMOS reaching a plateau in power-efficiency

– Cooling costs of new equipment will increase

• 1 MW for latest Cisco platform, CRS-1

2

Network redundancy/variability in traffic

3

Redundancy

Traffic variability

Underutilized links

In more than 40% of 5-min time

periods the traffic changes at least

by 20% percent

Datacenter Networks

4

[Al-Fares et al., SIGCOMM ‘08]

Large degree of

redundancy

Network Energy-(un)proportionality

5

0

20

40

60

80

100

0 20 40 60 80 100

Pow

er

(% o

f peak)

Utilization (percent)

Ideal energy-proportionality

Existing networking hardware

Goal: Energy-Proportional Networks

6

0

20

40

60

80

100

0 20 40 60 80 100

Utilization (percent)

Ideal energy-proportionality

Goal

Existing networking hardware

Pow

er

(% o

f peak)

Possible Approach

• Make individual components energy-proportional

– Implementation and deployment challenges

• Limits of energy efficiency in CMOS

• Leakage current

• Always-on components, …

7

Our Approach (Ensemble)

8

• Dynamically match resources

to the load

make the ensemble

energy-proportional

Ensemble Approach Challenges

• Producing significant energy savings

• Meeting the SLOs

• Avoiding oscillations

• Ease of deployment

• Responsiveness to traffic variations

9

Routing table computation

• Routing that minimizes power consumption

– Multi-commodity flow problem, but with

additional constraints for power objective:

Links + routers (switches) on/off

– Problem is NP-complete

When traffic demand changes,

optimal routing changes!

Related Work

• [Gupta et al., SIGCOMM ’03]

− Greening of the Internet vision

• [Nedevschi et al., NSDI ’08]

– Local actions

• [Chabarek et al., INFOCOM ’08]

– Power-aware network provisioning

• [Chiaraviglio et al., GreenCom ’09],

ElasticTree [Heller et al., NSDI ’10],

GreenTE [Zhang et al., ICNP ’10]

– Online techniques

11

Responsiveness

Op

tim

ali

ty

How Often is Recomputation Needed?

12

0

1

2

3

4

5

6

M a y - 2 8 J u n - 1 J u n - 5 J u n - 9

De

ma

nd

[

Gb

ps

]

T i m e

t r a f f i c d e m a n d s

0

1

2

3

4

5

M a y - 2 8 J u n - 1 J u n - 5 J u n - 9

Re

co

mp

ut

at

io

n

ra

te

[

pe

r

ho

ur

]

T i m e

Routing table

recomputed

3-4 times per hour!

Geant2 - European academic

network

Recomputation Wastes Energy or

Causes Congestion

13

Sta

te-o

f-th

e-a

rt

Time

Recomputation causing energy waste

Recomputation causing congestion

REsPoNse

14

Energy-aware

Traffic Engineering

Runtime Traffic

Measurement

Energy-proportional

Routing Table

Computation

Traffic

Estimation

Online components

Offline components

Se

rvic

e-L

ev

el O

bje

ctiv

es

RE

sP

oN

se

REsPoNse in Action

15

Time

Online adaptation

Outline

16

Online components

Offline components

Se

rvic

e-L

ev

el O

bje

ctiv

es

Energy-aware

Traffic Engineering

Runtime Traffic

Measurement

Energy-proportional

Routing Table

Computation

Traffic

Estimation

Energy-proportional routing paths

17

Always-on paths provide a routing that

can carry low to medium amounts of

traffic at the lowest power consumption

On-demand paths start carrying traffic

when the load is beyond the capacity

offered by the always-on paths

Peak-hour traffic

Safety margin

Minimize power consumption

Failover paths are designed to

minimize the impact of single failures

K B

D G

C F

E H

A

J

Computing REsPoNse paths

19

On-demand paths

for additional

traffic

Always-on paths

for low demand

Failover

paths

Computation

off the critical

path

Network Topology

Device Power Model

Low-load TM Estimate

Peak-load TM Estimate

+ safety margin

(optional: latency

bound)

Outline

20

Online components

Offline components

Se

rvic

e-L

ev

el O

bje

ctiv

es

Energy-aware

Traffic Engineering

Runtime Traffic

Measurement

Energy-proportional

Routing Table

Computation

Traffic

Estimation

EATe [e-Energy ‘10]

• Online effort to shift traffic to inactivate on-demand paths

• Intermediate routers mark packets with link load

• Edge routers collect load info only on alternative paths

• Scalable

21

Dest Src

A B

C D

EATe Stability

RX RB RI RJ

RY

RC RM RN

RK

L

1: Collect (wIJ)

2: Announce (1)

2: Announce (1)

1: Collect (wNY)

3: Feedback (ABKL)

3: Feedback (ACKL)

Stable, converges

in a few RTTs

Evaluation Questions

• How energy-proportional is REsPoNse/EATe?

– ISP topologies

– Datacenter networks

• How quick is REsPoNse/EATe in shifting traffic?

• What is the impact of traffic aggregation on

application performance?

23

0

2 0

4 0

6 0

8 0

1 0 0

1 2 0

u t i l - 1 0 u t i l - 5 0 u t i l - 1 0 0

Po

we

r

[%

o

ri

gi

na

l

ne

tw

or

k

po

we

r]

U t i l i z a t i o n

e p n

o p t i m a l

Energy-Proportionality (ISP topology)

24

~30% energy savings

vs OSPF InvCap for

same traffic load,

close to optimal Op

tim

ality

optimal

InvCap

REsPoNse/EATe

Abovenet US ISP topology

Responsiveness

Responsiveness/stability (live)

25

0

1

2

3

4

5

6

7

8

4 4.5 5 5.5 6 6.5

Ra

te (

Mb

ps)

Time elapsed (s)

middle

lower

upper

10 Click routers in a diamond topology

(16 ms per-hop latency )

EATe quickly and in a stable manner shifts traffic as needed

(either to save energy or to avoid failed links)

EATe starts running Link failure

Responsiveness/Energy-Proportionality (datacenter)

26

0

2 0

4 0

6 0

8 0

1 0 0

1 2 0

0 2 4 6 8 1 0

Po

we

r

[%

o

ri

gi

na

l

ne

tw

or

k

po

we

r]

T i m e

e c m p

e p n ( f a r )

E l a s t i c T r e e - F o r m a l ( f a r )

e p n ( n e a r )

E l a s t i c T r e e - F o r m a l ( n e a r )

0

0 . 2

0 . 4

0 . 6

0 . 8

1

0 2 4 6 8 1 0

De

ma

nd

[

Gb

ps

]

T i m e

• k=4 fat-tree topology

• Sine-wave demand

– Each flow [0, 1Gbps]

– Near (localized)

– Far (non-localized)

REsPoNse/EATe

matches traffic changes,

expending the same

energy as ElasticTree

[Heller et al., NSDI ’10]

Impact on app. performance (live)

80

85

90

95

100

105

epr-lat50 InvCap50 epr-lat100 InvCap100

Perc

enta

ge (

%)

27

0

0.5

1

1.5

2

epr-lat50 InvCap50

Tim

e (

s)

Application performance and end-to-end latency

under REsPoNse-LAT is comparable to OSPF-InvCap at

both lower and higher utilization levels.

Live Modelnet experiment with VoD (BulletMedia [IPTV ‘07])

Conclusion

• REsPoNse/EATe

• Key idea: hybrid

offline/online approach

• Properties

• Stable

• Incrementally deployable

• Scalable

28

Responsiveness

Op

tim

ali

ty

REsPoNse/EATe offers an optimal or a close-to-

optimal solution, with good responsiveness

REsPoNse/EATe