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

[Xie Chongfeng <[e-mail]>]

Hi， folks，
It seems that current discussion has touched solution analysis, not only requirement analysis. Different solutions may have different number of stata table in the equipment, which may influence the end-to-end latency and throughput. Moreover, the increasing of state table should not cause more workload to network operation.
Best regards
Chongfeng






[e-mail]
 
From: Ron Bonica
Date: 2020-09-30 03:40
To: srcomp
Subject: Re: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY
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:
 
Minimize the number of FIB entries required to support a segment
Minimize the amount of FIB storage required support a segment
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 <[e-mail]> On Behalf Of Ron Bonica
Sent: Wednesday, September 23, 2020 3:27 PM
To: srcomp <[e-mail]>
Subject: [Srcomp] Comments on 3.1.3. REQ-8-17-STATE-EFFICIENCY
 
[External Email. Be cautious of content]
 
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