RE: Power aware networks : Comments requested from routing community

["Eric Osborne (eosborne)" <[e-mail]>]

The root of your position seems to be that if you don't use a link, you consume less power, and thus avoiding certain links means consuming less power means saving money.

I see two problems with this:

1) I'm not sure that's actually true.  SONET, for one, sends empty frames when there's no data, so the laser is always firing.

2) even if it was true, or if you had some analogue to 802.3az that you could use in backbones, I don't believe you'd save anywhere near enough money to make it worth it.  

For #1, please explain the circumstances under which leaving a link idle saves power, and explain how much power and what drives that power draw.

For #2, please see my example in my original email.




eric


> -----Original Message-----
> From: Shankar Raman [mailto:[e-mail]]
> Sent: Thursday, February 07, 2013 4:48 AM
> To: Balaji Venkat; Eric Osborne (eosborne)
> Cc: [e-mail]; [e-mail]
> Subject: Re: Power aware networks : Comments requested from routing
> community
> 
> Dear Eric,
> Looks like we have not been clear in conveying our idea.
> 
> We abstract the power consumed by every router/switch, use it as the power
> rating. We then assign it to the link as a metric characteristic to get algorithms
> like SPF and CSPF to choose the lowest power paths or any metric based routing
> algorithm.
> 
> So the link metric is a combination of power consumed including the physical
> link and router components. In effect the link metric is not just the physical
> link’s metric alone (but the cost of the power consumed by the router/switch on
> which it connects to the neighbor).
> 
> Just like routing protocols consider delay, hops as metric we consider this
> power consumption as yet another metric.
> 
> Thanks
> Shankar
> 
> -----Original Message-----
> From: Balaji Venkat
> Sent: Thursday, February 07, 2013 2:36 AM
> To: Eric Osborne (eosborne)
> Cc: [e-mail] ; Shankar Raman M J ; [e-mail]
> Subject: Re: Power aware networks : Comments requested from routing
> community
> 
> Dear Eric,
> 
> Comments inline...
> 
> Sent from my iPad
> 
> On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)"
> <[e-mail]> wrote:
> 
> > You aim to optimize core networks through traffic engineering such that
> some links can be shut down when not in use, or switched to lower power.
> 
> Actually the answer is a No. We do not advocate this approach. The main idea
> in bgp power path draft has a survey section on previous literature that we
> quote for reference and state that such approaches cause expensive equipment
> to be kept unused. You have quoted the survey section of the paper in the
> above sentence.
> 
> >
> > Have you done studies in core networks with real equipment that show the
> actual amount of money you could save with this approach?  Let's walk through
> a quick hypothetical network, you tell me where I got it wrong.
> >
> > draft-mjsraman-panet-bgp-power-path says " Power consumption can be
> >   reduced by trading off performance related measures like latency. For
> >   example, power savings while switching from 1 Gbps to 100 Mbps is
> >   approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts."
> 
> Again this is a survey section of the paper surveying the existing approaches.
> 
> >
> > but provides no documentation to back these costs up nor itemization
> > of where the power is consumed (amortized across the router?  linecard
> > optics?  DWDM gear?)
> 
> Our main intent is to allow traffic to follow low power paths through ASs (either
> through pce like entities or through modifying the bgp path selection
> algorithm) which consume the least power and possess the required bandwidth.
> By graphing the topology of a set ASs in the immediate neighbourhood using
> as-path-info strands typically for a provider manning multiple ASs within the
> providers own control this mechanism will let large chunks of traffic belonging
> to a macro FEC traverse such low power ASs through an inter-as te MPLS lsp
> computed by a pce like entity and setup by RSVP-te.
> 
> The use of the metric, the way the pwr metric is arrived at , the computation of
> the topology of ASs, consequent CSPF and then mapping the traffic to the
> constructed LSP is the main focus if this paper. For dampening fluctuations in
> the metric which are frequent heuristics algorithms are suggested.
> 
> By no means are we advocating shutting off links. This scheme facilitates even
> the follow the moon strategy naturally.
> 
> 
> >
> > Let's assume that this is true and that it is linear, so that you burn
> > 4W per Gb.  (side note: I suspect this is inaccurate and that scaling
> > is sublinear, but let's go with it because if it's sub-linear you have
> > even less of a use case.  I also think the real world is far more
> > complex, as you have all the optical transport gear to worry about.
> > But let's go with it for now.)
> >
> > Running a 100Gb link thus draws 400W.
> >
> > Let's say you have a backbone with (300) 100Gb links.  Total power
> > consumption is thus (300*400) == 120 kW
> >
> > Running all these links for 24 hours thus draws 120*24 == 2,880 kWh
> > == 2.8mWh Power costs are maybe $0.10/kWh in the US.  Double that to
> cover the cost of cooling, so $0.20/kWh.
> > Thus, running the entire backbone costs $0.2 * 2,880 = $576/day.
> $210,000/year.
> > Let's say your approach can save one third of the power cost, which means
> about $70,000.
> >
> 
> 
> 
> > An operator with 300 100Gb links in a network has hundreds of millions of
> dollars worth of gear and millions or tens of millions in payroll alone.  If you cut
> $70k from their opex they probably wouldn't even notice.  That's one or two
> salaries, or 0.002% of what Time Warner spent on advertising in 2006 (see:
> http://gaia.adage.com/images/random/FactPack06.pdf).  It is a drop in the
> bucket, if that.  And your proposal comes with significant work attached to it,
> and significant risk.  If your 40 years of experience in the network industry don't
> help you understand the risks you're asking an operator to take then you're
> missing a crucial part of any potential real world solution.  I do not think your
> work should be presented at the IETF unless it makes a much stronger
> argument that its benefits outweigh its costs.
> 
> Again we are not asking the operator to shut off the equipment. He needs to
> keep it running as long as he has traffic to carry except that the pce makes a
> computation every time a large FEC of traffic needs to be carried through his
> ASs through a path that consumes the least power with the links therein having
> the required bandwidth. The ratio of consumed power to the available
> bandwidth is the metric that is used. Consumed power relates to a weighted
> average of the power consumed within the AS including the edge and core
> devices while the available bw relates to the links ingressing into the AS at the
> ASBRs that are the inter connectors between the ASes.
> 
> 
> So in summary, we do not advocate shutting off links at all. In fact we disagree
> with that approach. The scheme we advocate tries to optimise the power
> consumption using the metric based approach with some heuristics.
> 
> Hope this helps.
> 
> Thanks and regards,
> Balaji venkat
> >
> > These sorts of power optimizations all seem to be "here's how you reshape
> the problem so that you can throw a linear problem solver at it".  For example,
> [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ].
> I've never seen anything which shows how much more work it will be for a
> network operator or which quantifies the actual savings.
> >
> > If you can demonstrate significant savings in real networks at little or no cost
> to operators, you have an idea worth pursuing.  If your idea will cause more
> operational angst (e.g. not knowing whether your unused capacity will be there
> when you need it because you shut a third of it off all the time, increased risk of
> equipment failure from constant power-cycling, operational tools and training
> and expertise required to manage, deploy and troubleshoot variable-power
> links and the centralized NMS required to run them, etc etc etc) then it will find
> little traction.  Green-TE and power-aware BGP have been floating around for a
> while and have seen no real uptake in the WGs as far as I can see.  Is that not to
> be taken as an indication that there may be no real-world interest in them?  If
> not, what would it take to convince you?
> >
> >
> >
> > eric
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Balaji venkat Venkataswami
> >> Sent: Wednesday, February 06, 2013 1:53 PM
> >> To: [e-mail]
> >> Cc: Shankar Raman M J; [e-mail]
> >> Subject: Re: Power aware networks : Comments requested from routing
> >> community
> >>
> >> Dear Curtis,
> >>
> >> As already stated to you in a private email, "We" are a group of
> >> people with 40 years of collective industry experience in the
> >> networking industry. We dont need to be patronized by anybody since
> >> we have independent minds that have the capability to digest
> >> information not based on somebody else's interpretation of how future
> >> networks need to be built and how power reduction needs to play a part in
> it.
> >>
> >> As you might recall one such research paper on GreenTE by Beichuan
> >> Zhang rang a lot of bells in the IETF by collecting the ANRP prize.
> >> So please dont misstate facts as you might know them and shove your
> >> ideas of how networks are built down our throats.
> >>
> >> We think the IETF is a free and fair body that accepts opinions and
> >> ideas from all sides. We want to keep this a free and fair
> >> organization. So incumbent people like you ought to encourage us and
> >> have a fair argument when we present such work to you. Dont follow the
> policy of exclusion to the nth degree.
> >>
> >> It is but fair to say that you seem to be in a minority on this
> >> matter. Nobody else responded with unkind misstatements of facts and
> >> mis-understanding of our technical antecedents.
> >>
> >> Suffice to say that if we get an opportunity to present this (since
> >> IETF is OUR organization too) you need not sit through it. If you
> >> want to give us a fair hearing please follow a policy of kind
> >> inclusion and not create a ruckus about us research folks trying to
> >> make an earnest attempt at some practical research that could well save
> the planet.
> >>
> >> Yours sincerely,
> >> Thanks and regards,
> >> balaji venkat and shankar raman
> >>
> >> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar <[e-mail]>
> 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].
> >> com
> >>
> <mailto:CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv%2BOFon_9_4Oij61e11r9w@
> >> 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
> >>
> >>
> >