Re: Power aware networks : Comments requested from routing community

[Hannes Gredler <[e-mail]>]

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
>