Balaji, This response was directed to Hannes, but I'll point out that we do have a homenet WG within IETF. See inline.
Curtis In message <cahf4apmv595uodr1dnwhugzuunbmanrlpcyfizn3nqn8dmh...@mail.gmail.com> Balaji venkat Venkataswami writes: > > 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 ? Perhaps homenet WG could take on work in this area. > 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. There is no routing based solution but there are ways to put home devices into standby or otherwise save significant amounts of power. > c) So we can optimize power only on what we can control. What are your > views on this ? If "we" is IETF, IETF can do work in home networking and historically has done lots of work in the applications area and now has a homenet WG which could recharter but may feel that power expertise in home networking devices lies elsewhere. Curtis > thanks and regards, > balaji venkat > > On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler <[email protected]> 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 < > > cahf4apo9bekpk7qwa9fgjq9bnunhnv+ofon_9_4oij61e11...@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.... _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
