Re: [mpls] Concerns about ISD

[Tony Li <[e-mail]>]

Hi Haoyu,


> But if you check the cost of parsing ISD, this can still be a better choice.
> 
> Please explain that.  As previously discussed, parsing the full stack to find the bottom of the stack requires more read/load operations. That would seem to mandate poorer performance.
>  
> [HS] Assuming the label stack depth is L,  it needs L steps to reach the EH.  The question here is: what’s the reasonable value of L?   The total parsing cost and latency also need to include the parsing of the AD items. If we include this into consideration, we would see PSD would still win overall. Please see pg. 7 of the slides for the analysis https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda#no1 <https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda#no1>

You’re assuming a TCAM and your only metric here seems to be the storage cost.  Many folks don’t do parsing using a TCAM and the performance cost is in the reads, not in the storage.


> Moreover, in another draft https://www.potaroo.net/ietf/all-ids/draft-andersson-mpls-eh-label-stack-operations-03.txt <https://www.potaroo.net/ietf/all-ids/draft-andersson-mpls-eh-label-stack-operations-03.txt> we describe a way to avoid unnecessary scan of the label stack with the help from the control plane.


If you’re going to involve the control plane, then it would seem like Robert’s proposal (or what I understand of it), would imply that you push EVERYTHING into the control plane.  Why bother with data plane encodings at all?


> For the EH encoding efficiency, I appreciate your input. Currently it follows the IPv6 EH type (i.e., using NH + LENGTH to delineate every EH). There could certainly be room for improvement.
>  
>  
> Ok.  If I understand your proposal correctly, there are 4 octets of overhead (HEH) at the start. Then, for each network action, there would seem to be at least 3 octets of overhead, plus any associated data, plus alignment.
>  
> Let’s suppose that we want to encode NFFRR, entropy, and GISS in one packet.  By my math, the cost is:
>  
> EHI: 4 octets
> HEH: 4 octets
> NFFRR: 4 octets
> Entropy: 8 octets
> GISS: 8 octets
>  
> Total: 28 octets
>  
> Do I have that right?
>  
> [HS] It’s right if you think 8 octets are needed for Entropy and GISS


If I understand your proposal, and we want >8 bits for both of these fields, then each would require 3 octets of overhead. Storing the EL/GIS value might take 2 or 3 octets.  Alignment would take you to 8.

If I look at the same thing with the FAI draft, I get:

FAI: 4 octets
NFFRR: included in the above, so 0 octets
Entropy: 4 octets (30 bits, plus overhead)
GISS: 4 octets (30 bits, plus overhead)

Total: 12 octets


> (BTW, I wonder why we want to redefine entropy. We have already have a standard for it and we don’t need to do anything more about it ).


It’s true that we have a standard for it. It’s fairly common, so then the interesting question is what happens when it is present in the label stack along with MNA?  If we do not incorporate EL into MNA, then an implementation has to deal with both MNA and EL independently.  What order are they in? How do they interact? If we use the standard ELI/EL encoding, that’s 8 octets just for entropy.  OTOH, if we incorporate EL into MNA, then when using both, we can collapse the encoding.  For example, in the example above, entropy is 4 octets, resulting in a savings of 4 octets.  Half price! And that’s assuming that you don’t use the smaller entropy/GISS encodings which would give an even greater savings.

Tony