Re: [Srcomp] Comments on REQ-8-17-FWD-EFFICIENCY

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Ron, the metrics in this requirement are indeed valid, as lookups and header parsing can directly translate to impacts on pps, power, heat, cost.  These are things that operators tell me they care about and that we should analyze.

Let's change the rationale to reflect this.

Rationale: Performing multiple lookups per packet can impede the forwarding rate and functionality of many ASICS.
Parsing multiple headers per packet to perform those lookups can impede the forwarding rate and functionality of many ASICs.
These may translate to reduced pps or increased costs for operators.

During the analysis of each proposal, it can be determined just how many lookups would be required and their type, but this is analysis work for the analysis phase of this team's output.

Darren
________________________________
From: Srcomp <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Sent: Wednesday, September 23, 2020 3:06 PM
To: srcomp <[e-mail]>
Subject: [Srcomp] Comments on REQ-8-17-FWD-EFFICIENCY


Folks,



The metrics associate with REQ-8-17-FWD-EFFICIENCY are invalid. Currently, the metrics are:



  *   D.PRS(segment list): worst-case number of headers parsed during processing of the segment list.
  *   D.LKU(segment list): worst-case number of FIB lookups during processing of the segment list.



D.PRS assumes that parsing a second extension header is expensive on all ASICs. While it may be expensive on some ASIC’s it is extremely inexpensive on others. Retaining this metric doesn’t optimize the solution for operators. It merely creates an advantage for the ASIC that can’t parse additional extension headers efficiently.



D.LKU assumes that it is possible to determine how many lookups a particular compression mechanism requires. It ignores the fact that the FIB can be optimized to reduce the number of lookups. Furthermore, it fails to make a distinction between longest match lookups and index lookups.



Finally, this requirement should be stated from the network operators perspective, not the ASIC developer’s. The network operator doesn’t care how many headers were parsed or how many lookups were execute. It cares about:



  *   How many packet per second the ASIC can process
  *   How much power the ASIC consumes
  *   How much heat the ASIC generates
  *   How much the ASIC costs



Unless we can develop better metric for this requirement, we should drop it.



                                                                                           Ron








Juniper Business Use Only