Re: Power aware networks : Comments requested from routing community

[Thomas Nadeau <[e-mail]>]

	The other problem with this (frankly naive approach which has been investigated by many) is that yes, while adding in another constraint to the metric computation, it may result in unexpected consequences.    This is why it is likely to be more suitable as an IRTF topic of research until those "details" are sorted out. 

	--Tom


On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami <[e-mail]> wrote:

> Dear Hannes,
> 
> We are familiar with the presentation that you have referred to.
> 
> I have 3 questions for you.
> 
> a) While we agree with the presentation that you have mentioned, can we in the IETF have control over the home appliances and subscriber line kit ? Is there a methodology by which we can optimize the power consumption on these devices ?
> 
> b) The problem space that the IETF can take up can be only in the edge and core devices in the ISP networks and the Campus/DC/Metro etc...Assume that I have n devices today with the same bandwidth offering but differing power consumption
> footprint, is there a way today to automatically send traffic through low power paths in the topology of these devices.
> 
> c) So we can optimize power only on what we can control. What are your views on this ?
> 
> thanks and regards,
> balaji venkat 
> 
> On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler <[e-mail]> wrote:
> balaji,
> 
> may i put your attention to a talk that  francois lemarchand
> gave on future net 2010.
> https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf
> contains a copy.
> 
> slide 2 initially shows that the core and edge layer might be appealing
> due to their per-box power print. however slide 15 discusses the
> big picture where 99.99% of the power is burned by the home
> appliances and subscriber line kit.
> 
> Do you think that optimizing a part of the network which gives only limited
> overall savings is a worthwhile goal ? Note that SPs already ask their vendors
> about reducing the power footprint of those core devices by improved, (sometimes
> less functional) silicon forwarding engines.
> 
> /hannes
> 
> On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:
> 
> >
> > Balaji,
> >
> > "We" in the context of your first paragraph seems to be a
> > misrepresentation.  The authors of all of these drafts seem to be from
> > the same university in India.  From prior attempts on your part to get
> > a draft of this sort into IDR and a brief reading of a few of the
> > drafts that you have just submitted, you don't seem to have a good
> > understanding of how networks are built and how network equipment is
> > built from which to begin to attack the problem of reducing the power
> > consumption of these networks.
> >
> > If you want to try to advance a research paper with your theories on
> > power reduction, please choose an appropriate venue such as a refereed
> > technical journal.
> >
> > Curtis
> >
> >
> > In message <[e-mail]>
> > Balaji venkat Venkataswami writes:
> >
> >> Dear all,
> >>
> >> We are a group of research and industry individuals tied together with a
> >> common goal towards reducing the energy consumption in the core and edge
> >> networks.
> >>
> >> We present a metric-based hierarchical approach to reduce power consumption
> >> in core and edge networks. The proposal considers both unicast and the
> >> multicast cases. For unicast, the metric considered is *consumed-power to
> >> available-bandwidth* and for multicast the metric is *consumed-power to
> >> available-replication-capacity.*
> >>
> >> With unicast, the metric is used to determine a low-power path between
> >> sources and destinations. With multicast, the metric serves the twin
> >> purpose of finding low-power multicast paths as well as multicast
> >> replication points.  We evolve multiple techniques at various hierarchical
> >> levels. One at the Inter-AS level, Inter-Area level within the AS and
> >> intra-Area within an AS. Additionally, the proposed method can also be used
> >> to determine disjoint or redundant paths for load balancing or fault
> >> tolerance. Additionally since TCAMs are one of the biggest power guzzlers
> >> in all the components on a router/switch, we have presented a solution for
> >> intra-AS purposes to use the TCAM according to the traffic matrix passing
> >> through the system and shut down those TCAM banks that are unused. With
> >> this in mind, we have also advocated taking into account a TCAM-POWER-Ratio
> >> in order to compute the paths from source to destination based on this
> >> metric. Once low-power paths, in either the unicast or the multicast cases,
> >> are identified then currently available traffic engineering techniques
> >> could be used to route the data packets. In the case of inter-AS BGP path
> >> selection is also modified to arrive at paths which are low-power paths.
> >>
> >> Our main objective is as follows...
> >>
> >> We now outline four important aspects that any approach for power reduction
> >> should be capable of addressing.
> >>
> >> *Should cater for both unicast and multicast scenarios*
> >>
> >> Multicast provides an important scenario for the Internet. Today, most
> >> proposals consider mainly low-power path routing with unicast traffic.
> >> Multicast traffic has received a lot of attention in wireless networks, but
> >> not in the wired domain. Any new proposal should be able to address both
> >> the unicast and the multicast traffic scenarios. Having different methods
> >> for these two scenarios might lead to unnecessary processing burden in the
> >> routers, which might hinder its scalability.
> >>
> >> *Should not rely on just switching off unused links*
> >>
> >> Most approaches to optimize energy pursue the following approach: measure,
> >> monitor and respond to the system energy usage by switching off unused or
> >> under-utilized links. Such an approach could be effective for reducing
> >> power locally. The effect on the network is not clearly understood.
> >> Further, the power usage involved in turning on and rebooting/reconfiguring
> >> the device is often not explicitly considered. We note that Service Level
> >> Agreement (SLA) requirements may not even permit the links to be switched
> >> off. Also services provided by ISPs like Virtual Private Networks (VPNs)
> >> can be affected by such re-routing decisions.
> >>
> >> *Should follow an hierarchical and distributed approach*
> >>
> >> For scalability, it is important that the algorithms proposed for inter-AS
> >> should also be applicable to intra-AS situations. Networks do not work in
> >> isolation, so any proposal should be both distributed and hierarchical. The
> >> algorithms should be applicable at every level of the hierarchy.
> >>
> >> *Should  provide incentives for ISP for adoption*
> >>
> >> The engineering proposals should be aligned with commercial incentives for
> >> rapid and widespread adoption. Today, the device manufacturers and the ISPs
> >> operate independently of each other, and there is no incentive for
> >> manufacturers to work towards low-power and high bandwidth devices. An
> >> ISP=92s revenue model is based on the consumed bandwidth, which in turn lea=
> >> d
> >> naturally to more power consumption. If the proposed method chooses routers
> >> that consume low-power and increase the data flow through them, then this
> >> indirectly provides encouragement for ISPs to purchase low-power and high
> >> bandwidth devices.
> >>
> >>
> >>
> >> We now present our metric-based proposals in the below mentioned drafts
> >> which addresses the aforementioned design aspects.
> >>
> >> We would like the routing community to provide feedback on these drafts. We
> >> also intend to present this work in an abridged format in the upcoming IETF=
> >> .
> >>
> >> The drafts are as follows....
> >>
> >>
> >>
> >>
> >>   - mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-mjsrama=
> >> n-panet-bgp-power-path>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bg=
> >> p-power-path-timing.html>
> >>    Inter-AS-Proposal
> >>   - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html=
> >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ec=
> >> mp-redirect-power-repl-cap-timing.html>
> >>    Multicast
> >>   - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/draft-=
> >> mjsraman-panet-inter-as-power-source>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in=
> >> ter-as-power-source-timing.html>
> >> Inter-AS
> >>   Proposal
> >>   - mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-mjsraman-=
> >> panet-inter-as-psp>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in=
> >> ter-as-psp-timing.html>
> >> Inter-AS
> >>   Proposal
> >>   - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/draft-m=
> >> jsraman-panet-inter-as-psp-protect>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in=
> >> ter-as-psp-protect-timing.html>
> >> Inter-AS
> >>   Proposal
> >>   - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/draft=
> >> -mjsraman-panet-pce-power-mcast-replic>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pc=
> >> e-power-mcast-replic-timing.html>
> >>    Multicast
> >>   - mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-mjsraman-pan=
> >> et-pim-power>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pi=
> >> m-power-timing.html>
> >>    Multicast
> >>   - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/draft-=
> >> mjsraman-panet-tcam-power-efficiency>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tc=
> >> am-power-efficiency-timing.html>
> >> TCAM
> >>   related
> >>   - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/draft-mjsra=
> >> man-panet-tcam-power-ratio>
> >>    (timeline<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tca=
> >> m-power-ratio-timing.html>)
> >>   TCAM related
> >>   - mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-mjsraman-pc=
> >> e-power-replic>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-powe=
> >> r-replic-timing.html>
> >>    Multicast
> >>   - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/draft-m=
> >> jsraman-panet-intra-as-psp-te-leak>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in=
> >> tra-as-psp-te-leak-timing.html>
> >> Inter-Area
> >>   within an AS
> >>   - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-mjsram=
> >> an-panet-ospf-power-topo>
> >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-os=
> >> pf-power-topo-timing.html>
> >> Intra-Area
> >>   within an AS
> >>
> >> We understand it is a lot of matter to go through. We would much appreciate
> >> if some of you could review the inter-AS proposals while others take up
> >> multicast and Intra-AS unicast and multicast.
> >>
> >> Thanks again for your time on this matter.
> >>
> >> thanks and regards,
> >> balaji venkat
> > _______________________________________________
> > rtgwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtgwg
> >
> 
> 
> 
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg