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

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

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 28 Sep 2020 06:36:51 +0000

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 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Wednesday, September 23, 2020 3:06 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] Comments on REQ-8-17-FWD-EFFICIENCY

Folks,

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.

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:

                                                                                           Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 28 Sep 2020 18:28:40 +0000

Darren,

Consider D.PRS. You may be able to say that Compression Mechanism A uses only a Routing Header while Compression Mechanism B uses a Routing Header and a Destination Options Header (DOH). But what does that really mean?

Some would argue that it must cost *something* to process the DOH. Therefore, using one extension header must be better than using two. However, it the cost of processing the DOH is close enough to zero, D.PRS isn't worth considering. Furthermore, you would mislead the reader if you reported D.PRS without mentioning that its cost was extremely minimal.

The cost of processing the DOH can be measured on the ingress nodes, transit nodes, segment endpoint nodes, and the destination node. The following are metrics on my platform:

  *   On ingress nodes, the cost is zero, provided that using two extension header types doesn't increase the size of the packet beyond an 128-byte boundary
  *   On transit nodes,  the cost is zero because transit nodes don't process extension headers
  *   On segment endpoint nodes, the cost is zero, because segment endpoint nodes don't process DOH
  *   On the egress node, the cost is minimal. It is equal to the sum of the following costs:
     *   Examining Segments Left in the Routing header
     *   Calculating the starting address of the DOH

                                                                                                      Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Monday, September 28, 2020 2:37 AM
To: Ron Bonica <[email-masked]>; srcomp <[email-masked]>
Subject: Re: Comments on REQ-8-17-FWD-EFFICIENCY

[External Email. Be cautious of content]

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

Folks,

                                                                                           Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 28 Sep 2020 18:54:52 +0000

Darren,

Consider P.LKU. On may platforms, some lookups are more expensive than others. For example:

  *   Longest Match Lookups (e.g., IPv6, IPv4) are relatively expensive
  *   Indexed Lookups (e.g., MPLS) are relatively inexpensive.

If you want to keep this metric, you should at least split it into the following:

  *   D.LKU-LM (segment list): number of Longest Match FIB lookups during processing of the segment list.
  *   D.LKU-I (segment list): number of Indexed FIB lookups during processing of the segment list.

You might also want to mention that Indexed lookups are less expensive than longest most platforms.

                                                                               Ron

Darren

Folks,

                                                                                           Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 28 Sep 2020 19:03:48 +0000

Folks,

If we retain these metrics, we should also include:

  *   P.BSF - The number of bit shifts required
  *   P.EX0 - Number of fields in the routing header that must be examined when Segment Left is equal to 0
  *   P.EX1 - Number of fields in the routing header that must be examined when Segment Left is greater than 1

                                                                          Ron

Darren

Folks,

                                                                                           Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 30 Sep 2020 03:37:36 +0000

Hi Ron, I don't see why you would propose the inclusion of the existing metrics be dependent on adding additional metrics...

However, if I generalize your proposed metric it comes out to:
- At a segment endpoint a packet is received
- if It is destined to a local SID
  - For each header/extension header processed
     Count the number of read and write operations to process the header

Any source routing solution requires a segment endpoint node to perform:
- some number of lookups to identify the segment,
- some number of headers to be parsed,
- an IPv6 header Destination Address rewrite.

I don't see how you can quantify read and write operations during header processing.
Simply counting the headers processed should be sufficient as an approximation of the forwarding efficiency and your proposed metrics.

Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]>
Sent: Monday, September 28, 2020 3:03 PM
To: Darren Dukes (ddukes) <[email-masked]>; srcomp <[email-masked]>
Subject: RE: Comments on REQ-8-17-FWD-EFFICIENCY

Folks,

  *   P.BSF – The number of bit shifts required
  *   P.EX0 – Number of fields in the routing header that must be examined when Segment Left is equal to 0
  *   P.EX1 – Number of fields in the routing header that must be examined when Segment Left is greater than 1

                                                                          Ron

Darren

Folks,

                                                                                           Ron