Re: [bmwg] draft-cprjgf-bmwg-powerbench-01

[Qin Wu <[e-mail]>]

Resending this reply to fix indentation issue. Sorry for inconvenience for you.

Hi, Luis:
Thank for your valuable comments and input ,please see my reply inline below.
For other authors, feel free to chime in if there is anything missed.
发件人: bmwg [mailto:[e-mail]] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2024年3月6日 6:52
收件人: Carlos Pignataro <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: Re: [bmwg] draft-cprjgf-bmwg-powerbench-01

> Dear authors,

> I have gone through the document. Some few comments from my side:

>-  I find the formulation in 2.1 and 2.2 a bit confusing. I understand that Ti represents each of the active interfaces in the router. What is not evident for me is the applied weights for each interface, the Bi values. What is represented by these weights? All sum up 1, but the weights of the ingress interfaces is
> equivalent to the egress ones?

[Qin Wu] No, Ti, Bi is not calculated per interface, but per traffic load level.
See table 1 of  ETSI ES 203 136, Ti represents the total capacity of all interfaces of one single network device for each traffic load level, Bi represents applied weights for each traffic load level instead of each interface, the sum of B1 to B3 equal to 1, the weights vary based on equipment type and location of the equipment type, whether the network equipment has sleep mode support. With network equipment without sleep mode, B1,B2, B3 are set to 0.1,0.8,0.1.

> - The value “m”, identified as number of traffic load levels, I assume is different from the “m” suffix used for Ti and Bi, right?

[Qin Wu] the value “m” represent the number of traffic load levels, i in Ti and Bi MUST be less than or equal to m, e.g., m is 3, i<= 3.

>-I think 2.1 and 2.2 would benefit from a numerical example.

[Qin Wu] Sounds reasonable comment to me, thanks, will see how to reflect in the update.

> - Regarding traffic loads it is proposed to consider 100%, 30% and 0%. Thinking on operational situations, I think some values are informative but not useful at all.

[Qin Wu] 30%,10% are not randomly selected traffic load level percentage, see Table 1: Traffic load level and weight multipliers of ETSI ES 203 136, for core equipment, the medium traffic load level percentage is set to 30%, for Edge/access equipment, the medium traffic load percentage is set to 10%. 50% medium traffic load level percentage is not specified in any non-IETF standard, if my understanding is correct.

> Let me explain. As rule of thumb, operational networks are usually kept to a maximum load of 50% (roughly speaking) in a way that if some link or node fails, the protection paths / nodes can absorb the excess traffic. This should be something exceptional,

[Qin Wu] umm, interesting case, in this case, protection or backup is considered for test scenario. At this moment, we don’t support this extreme case.

> and I think that the in such circumstances is more critical to guarantee no traffic losses than being efficient in terms of energy consumption, assuming that situations are temporal. So probably is better to concentrate in what would be the typical working regimes in terms of network occupancy (peak, valley
> and average values) rather than consider the extreme cases (which are good to know but less relevant in the day-by-day operation).
[Qin Wu] See above, I think we are aligned, don’t test 50% extreme case, but 30% use case is not extreme use cases.
> - Interestingly, you count on a power meter as reference system or ground truth of the energy consumption. I think a missing benchmarking test is the one assessing the validity of the energy / power values reported by the node sensors. I mention this because thinking on possible ways of automating
> optimization actions in the network, the sensors’ information is the one that can be retrieved automatically from production nodes. So understanding how close / far are those from the reference provided by the power meter is quite interesting.

[Qin Wu] Interesting point, I think each instrumental engineer can be equipment with such power meter, power meter is also very useful for centralized procurement of large amount equipment from multiple  vendors. We will see how this case can be considered or designed.


> - In section 6.2 you comment about the base power. Here we can find different situations. On one hand, the monolithic routers / switches, and on the other hand, the modular ones. For monolithic equipment section 6.2 is fine. For modular ones, probably it would be a good practice to determine on one hand the base power of the basic elements (processors, fans, etc) and then the increments due to each of the used cards, without and with traffic.

[Qin Wu] Good point, at current draft, we only support benchmark on monolithic routers/switches, modular cases have already been supported by ETSI standard, we will see how to support modular case in the next version. Probably add section 6.3 for module power. Thanks.

> - It is described the fact of heat dissipation. Maybe temperature of the equipment could be also a interesting data to be reported, taking into account that some equipment should work under extreme temperature conditions in certain environments.

[Qin Wu] Not sure extreme temperature condition is in the scope. Note than power measurement we performed is under the condition such as Room temperature: 23 degree to 27 degree.

> - While the benchmarking is performed determining common traffic load levels, other common principles should probably apply: usage of transceivers of the same kind, same set of protocols / configuration, etc.


[Qin Wu] Good comment, I believe your comment is related to section 4.2 “Traffic and Device Characterization”, will see how to support in the next version, thanks.


> Thanks, best regards

> Luis

De: bmwg <[e-mail]<mailto:[e-mail]>> En nombre de Carlos Pignataro
Enviado el: lunes, 4 de marzo de 2024 23:53
Para: [e-mail]<mailto:[e-mail]>
Asunto: [bmwg] draft-cprjgf-bmwg-powerbench-01

Hi, BMWG,

Today, we posted a new revision of:
https://datatracker.ietf.org/doc/html/draft-cprjgf-bmwg-powerbench-01
https://www.ietf.org/archive/id/draft-cprjgf-bmwg-powerbench-01.html

and we welcome your review, feedback, suggestions, and input!

Thanks!

Carlos, Romain, Giuseppe, and Qin.

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição