Re: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Mingui Zhang writes:
> 
> Hi Curtis,
>  
> Please find my comments in-line below.

Hi Mingui,

> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On Behalf Of
> >Curtis Villamizar
> >Sent: Friday, March 22, 2013 9:50 AM
> >To: Alvaro Retana (aretana)
> >Cc: [e-mail]
> >Subject: Re: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt
> >
> >
> >Alvaro,
> >
> >I'm not sure what it means to put a OTN interface in a "low power
> >state".  OTN and SONET interfaces are a continuous stream of bits at a
> >constant rate dictated by the ITU-T.  The rate is not adjustable.  It
> >doesn't save any power by sending GFP null frames over OTN links.
> >
> >Since most long haul router to router links are Ethenet across the
> >room, followed by long stretches of OTN, there may be no significant
> >benefit to putting the short Ethernet into lower power mode.  Plus as
> >discussed at IETF-86, the Ethernet low power mode applies only to
> >copper Ethernet (10/100 Mb/s, 1 Gb/s copper) and not to the fiber
> >forms of Ethernt used by providers.
>  
> The methodology from my side is to put those optical components in a
> manageable DOWN state (sleeping). If protocol work creates the
> opportunity for them to stay in the sleeping state for seconds or
> minutes, energy saving can be significant.  Fiber forms for Ethernet
> does not support micro-sleeping mode, but they may support
> deep-sleeping mode. PHYs can negotiate a longer time to stay in
> deep-sleeping mode.

BTW- That sounds to me like solution space.

As stated from Pat (don't have her last name handy) at IETF-86, there
was a reason IEEE wrote the existing standard for copper Ethernet
only.

It is harder to power down a laser and power up.  It is very hard to
power down and power back up a temperature compensated finely tuned
laser used in WDM systems, particularly todays DWDM and ULH circuits.
Those can take over a minute to acheive stability, during which time
they cannot be used.  So if you could power down for an extended
period of time, maybe there would be hope.

> >So before anyone writes any more problem statements, requirements,
> >frameworks, or complete solutions for energy aware networks, we need
> >to have some research and some hard facts about where energy goes and
> >where there are opportunities to save energy.  
>  
> I agree that we should let numbers tell the truth. According to our
> observation, line-cards are the most power hungry part of high-end
> routers and switches. They can consume nearly 70% of the total
> power. Meanwhile, idle routers/switches consume more than 80% of their
> peak power. If we can shut-down components on line-cards or whole
> line-cards, we can save a considerable amount of energy.

Your observation used the topology of a real network but had nothing
to do with the power being consumed by the network who's topology you
used.

> This observation treats a router/switch as a black box. Our next step
> is to open this black box and see what further meaningful numbers we
> will get.

Yes.  And that is still in the research stage.

> >We also should be
> >asking whether providers and high end network equipment vendors see a
> >need for any protocol work in this area.  So far the answer is a
> >resounding "no".
>  
> Energy Efficient Ethernet (EEE) involves a great deal of protocol
> work. Network equipments supporting EEE have already been shipped
> around by vendors. Providers may not resist solutions that can save
> their OPEX, only if vendors can come up with workable ones.

And supports copper only.  Providers don't use copper Ethernet.

> >It is also worth pointing out that research so far has indicated that
> >the greatest total savings is the furthest down the food chain at or
> >near the customer network.  So the low power Ethernet applied to the
> >10/100/1000 copper used in homes and small business makes a lot of
> >sense.  IETF may not be the right place to attack the next layer up
> >the food chain, things like CMTS to CM (cable modem termination
> >systems to cable modem) or DSL efficiencies.
>  
> Power/Energy Aware NETwork needs the combination of "hardware work"
> and "protocol work". Protocol work should make use of the hardware
> characteristics. IOW, protocol work should create the opportunity for
> these techniques to save most energy.

The assertion that protocol work is needed is nothing more than an
empty assertion.  There are currently no facts to back it up.

> Energy saving for composite links may become another low-hanging
> fruit. As you pointed out, the traffic aggregation onto component
> links may impact the cooling system. We can have a test to see what
> will happen, whether we should have some limit on the aggregation.
>  
> Thanks,
> Mingui

I'm not convinced that there is any savings for composite link, or
today's simpler LAG.  The switching uses more power than the laser on
a short haul interface.  I'm not sure to shut down the transport
lasers.  If you move the switching to a smaller subset of cards, you
heat that subset of cards more and the fan has to run hard enough to
cool the hottest card in the chassis.  There may be no net decrease in
switching power, negligible laser power decrease, and an larger
increase in fan power, yielding higher power consumption for the same
amount of traffic.  AFAIK, no one has measured using the types of
equipment actually at a provider.  Using vendor data sheets and
extrapolating doesn't work.

Curtis


> >Curtis
> >
> >
> >In message
> ><[e-mail]>
> >"Alvaro Retana (aretana)" writes:
> >
> >[Chair hat off.]
> >
> >Hi!
> >
> >We just published an update (a refresh really) of the draft below.
> >
> >The draft is NOT a set of requirements to be solved in the realm of power
> >aware/energy efficient networking.  We are not trying to define
> >requirements on how to save energy, how much energy should be saved, how,
> >when or where.  Nor are we recommending any specific solution.
> >
> >So, what is it? ;-)   The intent of the draft is to "provide the tools and
> >knowledge necessary for protocol designers to modify network protocols to
> >best balance efficiency against performance, and to provide the background
> >   information network operators will need to intelligently deploy and use
> >protocol modifications to network protocols."
> >
> >In other words..  We recognize that saving energy may be in many people's
> >minds, but we also recognize that networks have been designed/deployed
> >with a set of business (availability, ability to satisfy customer SLAs,
> >for example) and application (min bw, jitter/delay budgets, for instance)
> >requirements in mind, which need to still be satisfied even while saving
> >energy.
> >
> >The draft goes on to evaluate considerations derived from the
> >business/application requirements that may be affected by applying common
> >methods of reducing energy (reducing the topology or reducing the link
> >speed, for example):  bw reduction, stretch, fast recovery, introducing
> >jitter and other operational aspects.
> >
> >As an example, we mention (section 5.1) that eliminating links from the
> >topology (shutting them down or putting them in a "low power state")
> >should result in lower energy utilization..but that it will also affect
> >the total available bw in the network.  The requirement then comes in in
> >the form of "Modifications to control plane protocols to achieve network
> >energy efficiency SHOULD provide the ability to set the minimal bandwidth,
> >   jitter, and delay through the network".  I'll leave you to read some of
> >the other examples/considerations and requirements.
> >
> >The end result of the draft is the definition of a framework against which
> >we can evaluate "the tradeoffs between modifications made to network
> >protocols to conserve energy and network performance metrics and
> >requirements".
> >
> >Thanks!
> >
> >Alvaro.
> >
> >
> >On 2/13/13 10:18 AM, "[e-mail]" <[e-mail]>
> >wrote:
> >
> >>
> >>A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >>
> >>
> >>	Title           : A Framework and Requirements for Energy Aware
> >Control
> >>Planes
> >>	Author(s)       : Alvaro Retana
> >>                          Russ White
> >>                          Manuel Paul
> >>	Filename        : draft-retana-rtgwg-eacp-01.txt
> >>	Pages           : 16
> >>	Date            : 2013-02-13
> >>
> >>Abstract:
> >>   There has been, for several years, a rising concern over the energy
> >>   usage of large scale networks.  This concern is strongly focused on
> >>   campus, data center, and other highly concentrated deployments of
> >>   network infrastructure.  Given the steadily increasing demand for
> >>   higher network speeds, always-on service models, and ubiquitous
> >>   network coverage, it is also of growing importance for
> >>   telecommunication networks both local and wide area in scope.  One of
> >>   the issues in moving forward to reduce energy usage is to ensure that
> >>   the network can still meet the performance specifications required to
> >>   support the applications running over it.
> >>
> >>   This document provides an overview of the various areas of concern in
> >>   the interaction between network performance and efforts at energy
> >>   aware control planes, as a guide for those working on modifying
> >>   current control planes or designing new control planes to improve the
> >>   energy efficiency of high density, highly complex, network
> >>   deployments.
> >>
> >>
> >>The IETF datatracker status page for this draft is:
> >>https://datatracker.ietf.org/doc/draft-retana-rtgwg-eacp
> >>
> >>There's also a htmlized version available at:
> >>http://tools.ietf.org/html/draft-retana-rtgwg-eacp-01
> >>
> >>A diff from the previous version is available at:
> >>http://www.ietf.org/rfcdiff?url2=draft-retana-rtgwg-eacp-01
> >>
> >>
> >>Internet-Drafts are also available by anonymous FTP at:
> >>ftp://ftp.ietf.org/internet-drafts/
> >>
> >>_______________________________________________
> >>I-D-Announce mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/i-d-announce
> >>Internet-Draft directories: http://www.ietf.org/shadow.html
> >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt