Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

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

As stated in the metric, it counts the number of FIB entries, and I think that's the right level of granularity.
The state efficiency metric (S) records the number of additional FIB entries (states) required by the proposed solution.

Given a set of node parameters "number of nodes in the network, number of local interface, number of adjacencies"

More forwarding state requires more resources in the ASICs. More forwarding state to maintain and update as part of operations in scaled deployments have an impact on the scale and performance that can be provided by an implementation. These are important considerations for costs when merchant silicon and white-box deployments are increasing.

Darren

________________________________
From: Ron Bonica <rbonica=[e-mail]>
Sent: Thursday, September 24, 2020 8:41 PM
To: Darren Dukes (ddukes); Chengli (Cheng Li); Ron Bonica; srcomp
Subject: RE: Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Darren,

This rationale is much better. Does it imply that the metric  should be stated in terms of bytes of memory required to support a network of a given size?

                                                                                                   ROn



Juniper Business Use Only
From: Srcomp <[e-mail]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, September 24, 2020 8:31 PM
To: Chengli (Cheng Li) <[e-mail]>; Ron Bonica <rbonica=[e-mail]>; srcomp <[e-mail]>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

[External Email. Be cautious of content]

Hi everyone, the rationale was transcribed incorrectly from the original email to the spreadsheet/document.  The email stated:

Rationale: Efficiency in bits on the wire and forwarding state are both important.  Optimizing one at the expense of the other may lead to issues in implementations.

This can be improved to take an operators point of view:

Rationale: Increasing the forwarding state in an ASIC results in an increase in memory usage.  Greater memory usage can result in greater costs for operators, or limit functionality.

Darren

________________________________
From: Srcomp <[e-mail]<mailto:[e-mail]>> on behalf of Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 24, 2020 5:57 AM
To: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; srcomp <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY


Hi Ron,



We may try to provide some text of rationale before dropping it?



I think the state efficiency is important for a solution. But some optimizations can reduce the state of a solution for sure.



How about let’s try to provide a better rationale and metric. When we are analyzing solutions, some conditions can be provided to adjust the results?





I try to add some text of the rationale.



   o  Rationale: Additional state will increase the complexity of control plane and data plane at a node. Also, removing per-flow state at middle nodes is the key advantage of SR architecture, which can simplify the network. The compression solution SHOULD NOT introduce extra state.



Regarding the Metric, does the state equal to the number of FIB entries? I doubt that.



   o  Metric:The state efficiency metric (S) records the number of

      additional FIB entries (states) required by the proposed solution.



      *  S(node parameters): the number of additional FIB entries for a

         node, given a set of node parameters consisting of number of

         nodes in the network, number of local interface, number of

         adjacencies.





Respect,

Cheng











From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Thursday, September 24, 2020 3:27 AM
To: srcomp <[e-mail]<mailto:[e-mail]>>
Subject: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY



Folks,



The description and the rationale are identical. Lacking rationale to justify this requirement, we should drop it.



The metric regarding  REQ-8-17-STATE-EFFICIENCY assumes that one can infer how many FIB entries a particular compression mechanism requires. It ignores the fact that a FIB can be organized in many ways. Some organizations will have more FIB entries than others.



Unless we can develop a better metric, this requirement should be dropped.





                                             Ron





Juniper Business Use Only