Re: Power aware networks : Comments requested from routing community

[Balaji venkat Venkataswami <[e-mail]>]

Dear Tom, Acee,

Thank you for your comments.

We are currently approaching IRTF for this very purpose.

Additionally we would like to state that there are existing mechanisms for
aspects like delay (QoS) being additional metrics for the computation of
paths inter-AS and intra-AS. We feel that this additional power metric can
be handled in a way similar to how say aspects like delay are handled today.

Since you have said that this approach has already been tried out, we would
request you to give us some of the citations which will be of help to us.
We have already searched literature available in the web today. In case we
have missed out anything your citations would help us.

Thanks and regards,
balaji venkat



On Thu, Feb 7, 2013 at 8:49 PM, Acee Lindem <[e-mail]>wrote:

>  +1
> Acee
>
>  On Feb 7, 2013, at 10:06 AM, Thomas Nadeau wrote:
>
>
>  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
>
>
>  _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>
>