Fred, On Jan 11, 2011, at 10:29 MST, Fred Baker wrote: > On Jan 11, 2011, at 9:10 AM, Shane Amante wrote: > >> It's probably better to say that a hash algorithm works well where >> individual, long-lived flows (regardless of traffic type) are a small-ish >> fraction of the physical BW of any individual component-link in a LAG or >> ECMP group. It's when those long-lived flows are a substantial portion of >> component-link's physical BW that a hash algorithm is ineffective and you >> either need higher capacity component-links or more "creative" techniques. > > Statistics we're seeing suggest that long-lived video flows (video-on-demand, > streaming media, netflix/youtube/etc) are becoming a fairly large subset of > internet traffic. You may have seen Wired's article on it > (http://www.wired.com/magazine/2010/08/ff_webrip/all/1) and the > far-better-thought-through rebuttal > (http://boingboing.net/2010/08/17/is-the-web-really-de.html).
I have. However, people need to put the [very poor] Wired article in context. Specifically, there's a significant difference between the aggregate amount of all Video traffic **versus** the size (bandwidth) of individual Video streams that will appear in the core of the network. IOW, as an operator, I don't have concerns transporting Terabits (and, more) of _aggregate_ Video traffic, so long as the _individual_ Video streams in that aggregate are "well distributed" amongst themselves and other traffic that would ultimately be output on a common set of component-links comprising a single LAG or ECMP group. By that I mean: - each has a relatively unique 5-tuple (since that's the only thing I can use, today, from the IP header, today, as an input-key for a load-balancing hash algorithm), to ensure there is the low(est) probability that all Video flows will get put onto the same component-link in a LAG or ECMP path; and, - the bandwidth of an individual Video stream is a small-ish fraction of the BW of a component-link comprising a LAG or ECMP path. IOW, why should I care about a 5, 10 or 20 Mbps constant rate Internet [Video] flow on a 10 Gbps component-link, (you're talking about .2% [2-thousands] of the overall physical capacity of a component-link)? 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. -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 --------------------------------------------------------------------
