Shane and all,
> > What causes pain and/or worry to us operators is when someone launches a > large *individual* "macro-flow"[1] at the network that start to represent > a decent fraction of the overall capacity of a physical component-link > underlying a LAG and/or ECMP path, (e.g.: and the following are only an > *example*: 200 Mbps, 500 Mbps, 1 Gbps, etc. on a 10 Gbps link). > Unfortunately, due to the fact that load-hashing algorithms are stateless > (and, thus, non-adaptive), that means that "well-behaved" microflows > (think: casual Web surfing, e-mail, etc.) are still co-mingled with those > large, fat-flows across all component-links in a common LAG/ECMP path > *without* taking into account BW utilization of individual component-links. > So, there is a much higher probability (or, oftentimes, certainty) of > congestion and packet loss causing pain to all users on the one (or, more) > component-links with fat, macro-flows on them that I can't capacity plan > for and I can't easily react to. [LY] Great analysis. As a result, it seems the necessary to differentiate those large flows (decent fraction of the component link capacity) from other "small" flows because there are few such large flows in the network and hash can't do well on a small flow space nor on a large flow space that mixed with huge number of small flows and a few large flows. Lucy > > -shane > > [1] Examples are: IPvX in IPvX tunneling, GRE, IPSec, "WAN acceleration" > type products that are used for extremely fast large file xfers, etc.= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
