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

["Chengli (Cheng Li)" <[e-mail]>]

Hi Wim and Ron,

I agree with Wim. There is value to show the times of lookup. Some forwarding efficiency MUST be dropped in any extra table lookup.

Please see my reply inline.

Respect,
Cheng



From: Srcomp [mailto:[e-mail]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Thursday, September 24, 2020 12:23 PM
To: Ron Bonica <rbonica=[e-mail]>; srcomp <[e-mail]>
Subject: Re: [Srcomp] Comments on REQ-8-17-FWD-EFFICIENCY

I do believe there is value in showing the lookups needed for a certain proposal for srcomp and compare them. The reason is this technology will be implemented by many asic (hopefully) and less lookups will be better. The more you need the more transistors/memory you burn and the result will be less performance in a given package. As such this is an important factor in the comparison of the options in my view.

In other words a solution that does 2 lookup versus 3 will be more future safe.

From: Srcomp <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Date: Wednesday, 23 September 2020 at 21:06
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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.

[Cheng] Sure, different hardware have different capabilities. We may specify what kind of hardware, correct? Also, why we only list the worst-case?

We should list all the possible cases, the best case, normal cases, and the worst case.

Also, the percentage of each cases should be provided. Like, in  0.1 percent to have the worst case, then there is no meaning to analysize it? But if in 10 or more percent we will meet the worst case, then it is valuable to have the data.

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.

[Cheng] Yes, FIB can be optimized to reduce the number of lookups, this should be explicitly noted.

Also, the forwarding efficiencies of using LPM and EM are different. But for some vendors’ hardware, they can make them almost the same. I think it depends on the hardware implementation. Perhaps, we can do some theoretical analysis?


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