how many bits of entropy do we need for load balancing?
Dear all: How many bits of entropy do we need for (ECMP) load balancing in the core? This question has kept coming up regularly in many discussions and drafts at the IETF. The IPv6 flow label is 20 bits but hardware implementations do their balancing only on a subset of that, e.g. 12 or 16 bits. There are drafts for MPLS, BIER etc.. that provide their own entropy bit fields of various sizes. I traced to a 6MAN discussion at IETF 78 a claim that 10 or 11 bits were enough. Did someone do the actual exercise? It would be neat to align the IETF specs in the making to whatever truth may be established in the core. Keep safe, Pascal
On Mon, 14 Dec 2020 at 16:58, Pascal Thubert (pthubert) via NANOG <nanog@nanog.org> wrote:
The IPv6 flow label is 20 bits but hardware implementations do their balancing only on a subset of that, e.g. 12 or 16 bits.
Why? I don't think it's fundamentally true. Even if we imagine your instruction set reading only 12 or 16, you can always read too much and shift. And I certainly don't think it's a meaningful contributor in HW design to read 20 bits or any other random bit size of entropy. Your question itself is interesting and I don't have a good answer. I guess the question should be 'to cover all practical networks', which means, we need to allow for potentially hundreds of interfaces, maybe millions of flows and potentially we need to allow highly biased hash_result => interface mapping, to deal with elephant flows. I think it's an answerable question, but not necessarily easy to answer. There is also the question what SHOULD be used as a flow key, and should the sender be able to affect that decision? https://ytti.github.io/flow-label/draft-ytti-v6ops-flow-label.html -- ++ytti
participants (2)
-
Pascal Thubert (pthubert) -
Saku Ytti