[EERG] Minutes EERG IRTF 84 meeting

Damien Saucez damien.saucez at gmail.com
Thu Aug 9 16:32:14 CEST 2012

Here are the polished minutes.

Q? mean a question, R! means an answer to that question. The
name in parenthesis is the name of the talker.

[DSA=xxx] means that xxx are personal notes/appreciation/missunderstanding


Damien Saucez


[DSA=approximatively 30 people in the room, to be confirmed by blue sheets,
among them, a dozen is active]

Welcome  (Rolf Winter)

link to mailing list: https://listserv.netlab.nec.de/mailman/listinfo/eerg

note well

We proceed today with 5 minutes pitches.

Q? how many people want to pitch?

R! no body ask for a pitch

One year ago a meeting, more attendants than today, we gave a

general description of the idea. Conclusion: people was positive

and said that yes, we have to work, but nothing happened on the

list. Many changes since then, now a lot of paper have been published

with energy efficiency in mind. The conclusion is that this is only the mailing
list that is not active.

Agenda for today:

- structure the problem a bit better

- scoping and figure out what people want to work on

- if interest, how to organize and what with the next month

As a reminder, the new idea of Lars is to let people to act as a RG for a year,


For energy efficient network (Samsung)
energy optimized operation

Look to keep QoS but while reducing energy efficiency

switch off or slow down interfaces when not necessary. Unfortunately, this is
an optimisation problem that is known to be NP hard.


    - a community or forum where to exchange ideas to tackle problem

    - share real network data (power, traffic, topology profiles)

Q? (Russ Verisign?):
           - do you think there is enough return on investment on shutting
down interfaces, do you measure it really is worth?

R! (Samsung)
           only 20W are necessary to send but up to now we consume up to
1,000W, so there is room for improvement

           [DSA= 1,000W or 100W?]
           [DSA= not understood the name of who is we]

Issue on power saving cloud system (Toshiaki Hitachi)

background: increase of power consumption with cloud use increase. In other
words, the more we are using the cloud, the more we consume.

Policies for power saving:
1. power saving by optimising VM allocation in DC
2. power saving by optimising VM allocation and path
3. power saving by optimising vm over DCs

    interface between an inter-DC network manager and a DC manager is needed

[DSA= no question or remark after the speech]

[DSA= no time to write title] (Huawei)
Idea: aggregate traffic on the whole network to idle some devices

Challenge: tradoff between enery efficiency and resiliency

        - what if traffic is suddenly partitionned?
        - how to deal with traffic peaks?

explain the difference between PRR [DSA=?] and … [DSA= don't understand what he
means there…]

[DSA= no question or remark after the speech]

RG Open Discussion (Rolf leads)

Routing and traffic engineering

Q (Rolf)? How many people to routing working group?

R! [DSA=5-6 people raised their hand]

Much of energy budget is put on end hosts, can we go further?

Q (Rolf)? Is there anything we can exclude already? Can we exclude some

Q? (Manuel Paul)
           - think about applicability and area, not only theory but
             reality. where actually safe energy
           - not possible right now to say where to cut
           - access link is obvious but core router can also,
           - can we do EE on per-flow/per-session, would be interesting
             to look at
           - mobile backhaul there is still the connection to the mobile
             network, more consideration there? Extend to shutting down
             the access point?
           - so all this just to say that it is very hard to exclude one
             part right now. It is not that easy to just switch off one
             part and not considering the whole. It's an area of control
           - how the network can make the difference between intentional
             switch off for EE and failure?
           - good use case for SDN

R! (Rolf): what people want to work in general and where?

Q? (Russ)
           - homenet would be a good point to look at, we would thus
             understand homenet requirements
           - applicability: DC is a big area, but not solution oriented,
             and what is the return on investment there?

Q? (Dimitri)
            - what is the difference between energy efficiency and power
            - in energy efficiency, you have a budget you want to use the
              best. While in power saving you just minimize the power you

R! (Rolf)
           - for me energy efficiency point encompass reduction

Q? (Dimitri)
           - a fundamental question: will we use current routing or
             create new routing?

R? (Rolf)
           - if people are interested why not changing routing, however,
             then we need to find people that will work on.

Q? (Dimitri)

           - difficult to have a global mean of accounting where you
             spend energy, maybe you save here but move there
           - how to know the solution is globally effective then?

Q? (Kalargianis)
           - homenet is an important area, we work on a system with radio
             + optic, but very hard to control all the access point
           - we can use some technique to reduce. How can we use network
             for beamforming and beamsetting? Should be worked on
             (currently worked on at AM)

Q? (Choi Samsung)
           - Jarri consumes a lot of energy in homenet, so yes, homenet
             is a good place to start

Q? (Brian)
           - reduce scope: look at motivation. Is it to increase
             functionality? reduce consumtion? reduce the total power
             consumption for the Internet? For the latter, the best then is to focus
             on homenet

R? ([DSA= unknown])  maybe you want to add devices without increase cost

Q? (Steward)
           - look at new network protocols, but for deployments it will
             be difficult, so if we want to see it one day, it needs to
             be something we are use to, at least from an operational viewpoint.

Q? ([DSA= unknown])
           - the major places: service provider (packets per energy),
             access and DC (PUI [dsa= ?]). To be valuable, we should
             convert this into an intelligible and common metric like cost in $ or
             carbon equivalent.

Q? (Dimitri)
           - management: control or knowledge
           - metric of where?

[dsa= do not really understand what Dimitri means]

R! (Rolf)
           - metric will depend our place. So what would we focused to?

Q? (Kostas)
           - kind of survey document? There are mechanisms now
             implemented in devices, but you lose info when you are high
             in the stack how can you use power efficiency feature (skype go silence so does
             your nic too???). Can we ignore what is about in the stack (how)? So how to
             make protos there to take this into account. So instead of just looking at the
             net level, we should look at the whole stack ([DSA= API for applications])

Q? (Dan)
           - we have such in Israel, at peek hours, we have to shut off
             features to avoid blackout
           - we need to defined precisely what energy efficiency means,
           - interested to participate

Q? (Brian)
           - yes, different for different usage, sure, but how to get one
             common metric such that we have common ground

Q? (Choi)
           - one device is easy: joule/bit; W/bps
           - not yet consensus for complex systems neither efficiency
           - I want to know the One metric!

R! (Kostas)
           - well this is physics, not applications

Q? (Kostas)
           - in some case, you can have burst of use (when the iDevice
             switches off, it burstly sends a lot of trafic)

Q? (Steward)
           - realistic approach with the application? What can we really
             do in the application place to have good in the routing

Q? (Benoit)
           - yes we want to reduce but what are we ready to lose? We have
             to lose something, somewhere!

R! (Kostas)
           - maybe we can come up with something with zero loss

Q? (Steward)
           - what you are ready to lose depends probably where you are on
             the network and the number of people behind

R! (Benoit)
           - yes, but you have TE, and now add an additional metric, the

Q? (Choi)
           - we have to use little to gain more

R! (Benoit)
           - IP phone is something you can do (EMAN) it is a little, but
             you have many of them so at the end you win a lot

Q?  ([DSA= unknown])
           - proliferation of endpoints, so good point reducing a bit
             there (x many)
           - service provider: cost per port is higher (SDN the cure for
             everything :-) ) cannot live with routing along we will have
             to go to application

Q? (Dimitri)
           - what minimum functionality we can have a fair comparison
             (common measurement) (e.g., in routing it is path length)
           - question about functionalities we are looking at. Yes but
             what features are we commonly accepting to be used now?

Q? (Bruce)
           - we should look at small network equipment instead of
             building/big infrastructure (because small networks are
             repeated everywhere  while building/big infrastructure is specific)
           - I have not seen useful information in the field about EE
           - we work on the metrics since many years, but we do not
             manage to get anything very significant
           - where is it reasonable/feasible to add sleep state (e.g.,
             TCP, BGP...)?
           - all what we do and deploy for security consumes a lot of
             energy, would be nice to quantify the total energy cost
             related to security

R! (Steward)
           - we have problem because we think punctual metrics, but this
             is multidimensional discontinuous metrics. Maybe change the
             term "metric" because it has too much background in our community
           - we can do scheduling so we know how long we can sleep!

Q? (Kalargianis)
           [DSA= not understood]

Q?  ([DSA= unknown])
           - optimisation is not so easy, how to avoid people doing the
             same decision at the same time, how to avoid
             self-synchronisation? (saw that with thermostats)

R! (Dimitri)
           - cooperative behavior vs selfish behavior

Q? (Steward)
           - anyway, at the end the question is "how much money!"

Q? (Manuel)
           - at the end looking at the SLA impact is not bad idea…
           - we want to make sure what we introduce doesn't cost the SLA,
             or what does it cost, such that we can have a way to tackle
           - maybe the user themself can see so he can contribute to
             that, the system does not act really, only tells the
             footprint (e.g., one google research = one coffee)

Q? (Alexendru (partner in greentouch))
           - are we really ready to communicate slower to google (wait a
           - we are looking how much it takes to send a packet, but hard
             to define the procedure, we have many methods, some metrics
             measure the NIC CPU, others how much energy is put in the air.
           - is dijkstra still working with energy metric instead of
             hops? In this case, probably good result if network is large
             in term of IP hops.... but how many hops do we have in houses?

Q? (Rolf)
           - there exists a small usb stick to make just networking, when
             PC goes to sleep, move the process to key a lot of energy is
             lost because computers stay up just for networking, the proxy
             key is used to keep the networking stack even if pc sleeps

Q? (Kostas)
           - use google instead of driving to go to the library... kind
             of metric :-)
           - can we have an energy star for applications? e.g, Skype
             better than XYZ VoIP, Cost of a call with an application,...

Q? (Benoit)
           - IETF = protocol design. Can we do provide guidelines to how
             to design protocols such that the protocol is  EE

R! (Rolf)
           - impose a "Energy Efficiency" section in every draft?

Q? (Rolf)
           - The EE must be crypto agile, when crypto go to sleep, they
             often have to renegotiate their timers

Q? (Brian)
           - measurement of energy use: it is inactivity that consumes a
             lot, not activity and this is very fundamental difference
             with what we are used to in real life

R! (Kostas)
           - then the more we will be able to go in sleep mode, the
             highest saving we will have.

Q?  ([DSA= unknown])
           - do we really need, e.g., 5,  protocols running at the same
             time? could be merge the protocols?

Q? (Didier)
           - do we want to avoid inactivity, or do we want to sleep. For
             example, we can use home wifi to offload, so we use this
             energy that was lost before and then we can use less energy in
             GSM networks

Q? (Manuel)
           - sleep state vs slow down, and how come sleep state can be
             integrated with the protocol?

Conclusion (Rolf)

Where do we go from here?

Q? (Rolf)
            - How many people plan to do something, really do something?

R! [DSA=10-15 people raised their hand]

Drafting an agenda, hopping to see some documents

Remember that the new procedure to become RG is to behave like one, so we have
to be active :-)

Do we need to propose to have virtual meetings (less energy), talk to these
virtual meetings on the mailing list to figure out the time Let's try once to see how
it goes. It of course does not limit side meetings, Video conferencing is possible

Maybe we can try to construct IEEE conference to have a forum with the

Thank you, enjoy the fireworks, be active on the mailing list, do documents.

More information about the Eerg mailing list