[EERG] Minutes EERG IRTF 84 meeting
Mingui Zhang
zhangmingui at huawei.com
Tue Aug 14 03:14:05 CEST 2012
Hi Damien,
Thanks a lot for the minutes!
Let me made some clarifications.
> [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
>
> problems:
> - 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]
>
Here, "PRR" should be replaced with "FRR" (Fast ReRoute).
The basic idea of power aware routing is to aggregate the traffic of the whole network when its lightly loaded with routing paths and tunnels intentionally set up. Some network devices will be idle and suitable to be shut down or put into some power saving mode. Then the whole network will become more energy efficient. We can see that power aware routing is _load sensitive_.
When network devices are shut down or put into power saving mode, the redundancy of the network is weakened, which makes the network easier to be partitioned by failures OR congested by traffic peaks.
FRR solutions can be leveraged to relieve power aware routing's impact on the network resiliency. However, as we know, FRR is load insensitive, which is a big difference between FRR and power-aware routing. Therefore, how to incorporate the power-aware routing into FRR or vice versa will be a good research topic deserves our effort.
Thanks,
Mingui
> -----Original Message-----
> From: eerg-bounces at listserv.netlab.nec.de
> [mailto:eerg-bounces at listserv.netlab.nec.de] On Behalf Of Damien Saucez
> Sent: Thursday, August 09, 2012 10:32 PM
> To: eerg at listserv.netlab.nec.de
> Cc: Florin Coras; Thierry Turletti; Mehdi.Mani at itron.com
> Subject: [EERG] Minutes EERG IRTF 84 meeting
>
> 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
>
> Regards,
>
> 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,
> then
>
> Pitches
> ======
>
> 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.
>
> Expectation:
>
> - 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
>
>
> issues:
> 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
>
> problems:
> - 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
> devices?
>
> 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
> saving?
> - in energy efficiency, you have a budget you want to use the
> best. While in power saving you just minimize the power you
> use
>
> 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
> definition
> - 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
> place
>
> 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
> EE
>
> 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
> them.
> - 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
> bit)???
> - 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
> academics
>
> Thank you, enjoy the fireworks, be active on the mailing list, do documents.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Eerg mailing list
> Eerg at listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/eerg
More information about the Eerg
mailing list