Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi Tony, please see inline comments.

From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Monday, April 18, 2022 10:36 AM
To: Haoyu Song <[e-mail]>
Cc: John E Drake <jdrake=[e-mail]>; Tianran Zhou <zhoutianran=[e-mail]>; [e-mail]
Subject: Re: [mpls] Concerns about ISD


Hi Haoyu,


Switch ASICs all use TCAM/CAM to do parsing for performance and NPs use microcode. You are right that in NP microcode you just write “if” branches to parse the headers. But each “if” costs extra clock cycles to process which are very expensive in NPs.


Sorry, I disagree.  Again, compute cycles aren’t nearly as expensive as memory operations.

[HS] Here “expensive” means the performance impact. NP is struggling to squeeze every cycle out of the processing, since the throughput is reversely proportional to the number of cycles a packet can finish its processing, and NP’s throughput already falls behind ASIC. Engineers need to handcraft the code to save a bit here and there. There’s never enough. The cycle is really a precious resource which can’t afford to squander.

Have you evaluated how much more complex (e.g., how many more “if”) it is to parse the FAI than a simple post-stack header chain? The result might surprise you. The inefficiency of the header encoding applies to any target platforms which will hurt the forwarding performance (or incur high hardware cost) and it will hit the old devices in use even harder.



Yes, I have.  The memory reads for parsing a header chain are extremely high.  No thank you.  The bandwidth requirements for the header chain are extremely high.  No thank you.

[HS] Not sure what you mean here. In ASIC, memory access is really fast. In software, every instruction and data need to be read from memory/cache. The more “if” in the code, the more memory accesses. And why header chain parsing requires higher bandwidth?


Ok, that saves you 4 octets, but costs you a bit in EHI. There’s only a finite number of bits available.  What do you do when they’re consumed?

[HS3] Resource is always limited everywhere and for any proposal, therefore we need to careful evaluate and admit use cases.


Well, I prefer proposals where there is more flexibility.

[HS] Header chain is more flexible and extensible. It’s used for all the headers AFAIK.

--Haoyu

Yes, determining the length requires reading the full ISD.

[HS3]This then would further complicate the parsing.


Considering that the parsing is probably trivial compared to performing the network action, I don’t understand the objection.



Absolutely true. Allocate popular functions first. :) If there are too many actions, then we could also consider a second SPL.

[HS3] We only know what’s popular for known use cases. We don’t know if a use case emerging in future is actually more important.


Agreed. Knowing the unknown is rather difficult.



So EH is twice as expensive as FAI.

[HS3] In terms of header overhead, this is true but only to this specific case. The number depends on how many functions and what functions are supported in a packet. For EH, HEH is a fixed 4 byte overhead, and all the others are equivalent.


This case seems like it might be pretty common.  EL is already common today and is likely to become more common as the use of ECMP proliferates.  I think we can anticipate that slicing will be common as the 5G folks seem to be strongly in favor of it. Mobile clearly isn’t going to go away.

Tony