[j-nsp] LAG/ECMP hash performance

[Eldon Koyle]

On Thu, Aug 29, 2019 at 2:52 AM James Bensley
<jwbensley+juniper-nsp at gmail.com> wrote:
<snip>
> Different parameters may or may not change the diffusion density, but
> they may increase the range of results, i.e. perfect diffusion over
> 2^2 outcomes vs. perfect diffusion over 2^6 outcomes.
>
> Also, ASR9Ks use a CRC32 on Typhoon cards but not of the whole frame,
> "Post IOS-XR 4.2.0, Typhoon NPUs use a CRC based calculation of the
> L3/L4 info and compute a 32 bit hash value." So actually, your results
> below should have good diffusion in theory if this was an ASR9K
> (although I'm sure that's not the case in reality). Is the Juniper
> taking (1) the whole frame into the CRC function (2) all the headers
> but no payload, or (3) just the specific headers fields (S/D
> MAC/IP/Port/Intf)?
<snip>

I think 802.3ad and ECMP both require a given connection to hash to
the same link to prevent out-of-order delivery.

Taking full frames or even full headers into your hashing algorithm
would likely break the expectation of in-order delivery (unless your
have the same vendor on both sides with something proprietary).
Ignoring that requirement, you could ditch hashing altogether and go
for round-robin.  Standards-compliant hashing implementations can only
look at header fields that don't change for a flow, namely src/dest
mac, ip, protocol, and port for TCP/UDP (maybe adding in certain MPLS,
VLAN, etc. fields or interface ids or other proprietary information
available to the chip that satisfies that requirement).

-- 
Eldon