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

[Mingui Zhang <[e-mail]>]

Hi Curtis,

Please find my comments in-line below.

>-----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.

>
>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.

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.

>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.

>
>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. 

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



>
>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
>
>_______________________________________________
>rtgwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtgwg
>_______________________________________________
>rtgwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtgwg