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

From: Ron Bonica <[email-masked]>
Date: Wed, 23 Sep 2020 19:26:41 +0000

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

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 24 Sep 2020 09:57:59 +0000

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:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, September 24, 2020 3:27 AM
To: srcomp <[email-masked]>
Subject: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Folks,

                                             Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 25 Sep 2020 00:31:10 +0000

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 <[email-masked]> on behalf of Chengli (Cheng Li) <[email-masked]>
Sent: Thursday, September 24, 2020 5:57 AM
To: Ron Bonica <rbonica=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Hi Ron,

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?

         adjacencies.

Respect,

Cheng

Folks,

                                             Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2020 00:41:44 +0000

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 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, September 24, 2020 8:31 PM
To: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

[External Email. Be cautious of content]

Darren

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

Hi Ron,

         adjacencies.

Respect,

Cheng

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

Folks,

                                             Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2020 00:51:27 +0000

Cheng,

I think you have just reminded us of a requirement that we missed. The compression mechanism MUST NOT require per-path state to be stored in transit nodes.

However, I'm not sure that FIB entries is the right metric for state.  Consider a FIB that contains *X bits of information*. If I represent that FIB with a relatively flat data structure, it contain fewer FIB entries, but require more bytes of storage. If I represent that same FIB with a more normalized data structure, it will contain more FIB entries but require fewer bytes of storage.

What do we want to optimize, bits of information, FIB entries, or bytes of storage.

                                                                                               Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Thursday, September 24, 2020 5:58 AM
To: Ron Bonica <rbonica=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Hi Ron,

Respect,
Cheng

Folks,

                                             Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 28 Sep 2020 05:53:27 +0000

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=[email-masked]>
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,

                                                                                                   ROn

Darren

Hi Ron,

         adjacencies.

Respect,

Cheng

Folks,

                                             Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 29 Sep 2020 19:40:42 +0000

Folks,

In https://mailarchive.ietf.org/arch/msg/srcomp/t9a7SRMaq0XNWdpT7ILBpx1hkW0/, Darren offers the following rationale for this requirement:

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

While this rationale admits a conflict between forwarding efficiency and state efficiency, it doesn't tell us *why* state efficiency is important. We all know, intuitively that it is important, but until we can articulate why it is important, we really don't know how to measure it.

When we strive for state efficiency, we might:

  1.  Minimize the number of FIB entries required to support a segment
  2.  Minimize the amount of FIB storage required support a segment
  3.  Minimize the amount of information required to support a segment

There is a conflict between 1 and 2. Assume that a Node A sends the exact same control plane stream to Nodes B and C. It contains some amount of information.

Node B stores the stream in a flat FIB structure. The FIB contains an IP Prefix Table and the IP Prefix table contains one entry for each reachable prefix. An IP prefix table entry contains the IP prefix plus many bytes of information describing each next-hop through which the prefix is reachable.

Node C store the stream in a normalized FIB structure. This contains an IP prefix table and a next-hop table. The IP Prefix table contains one entry for each reachable prefix. It also contains one entry for each next-hop. Each IP Prefix table entry contains an IP prefix plus a pointer for each next-hop through which the prefix is reachable. Each Next-hop entry many bytes of information describing each next-hop.

The FIB on Node B contains fewer FIB entries but consumes more storage. The FIB on Node C contains more FIB entries but consumes less storage. Both contain the exact same information.

So, when we optimize for state efficiency, which should we count, FIB entries, storage, or information. Darren suggests FIB entries. Why is this more important than storage or information?

Also, any data structure can be flattened to the point that it contains only one FIB entry. Is that what we want. When we measure state efficiency, what level of flattening or normalization do we assume. Why?

                                                                                  Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Ron Bonica
Sent: Wednesday, September 23, 2020 3:27 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Folks,

                                             Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 30 Sep 2020 04:54:50 +0000

Hey team, I want to point out a few things.

The measurement is not a comparison between B and C, and how they may implement internal storage structures for forwarding entries.
The measurement is of what B and C must store, regardless of their internal implementation choices.

Take two compression proposals 1 and 2:
proposal 1 requires A to asks B and C to store x entries
proposal 2 requires A to asks B and C to store 2x entries

Clearly proposal 1 requires fewer forwarding entries on both B and C regardless of how they arrange their internal storage.

Counting the forwarding entries is a useful way to compare proposals.

Darren
________________________________
From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Tuesday, September 29, 2020 3:40 PM
To: srcomp <[email-masked]>
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY

Folks,

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

While this rationale admits a conflict between forwarding efficiency and state efficiency, it doesn’t tell us *why* state efficiency is important. We all know, intuitively that it is important, but until we can articulate why it is important, we really don’t know how to measure it.

                                                                                  Ron

Folks,

                                             Ron