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 > <cahf4apo9bekpk7qwa9fgjq9bnunhnv+ofon_9_4oij61e11...@mail.gmail.com> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
