On Jan 9, 2011, at 7:05 PM, Steven Blake wrote: > The network doesn't control port numbers, so his argument obviously doesn't > apply to ECMP or LAG.
There are more than two common uses of load balancing. ECMP is a side effect of routing; we decide to multipath route when we know of two next hops that get us to a remote destination with the same routing metric. Link Aggregation (LAG) is what is done when I have multiple paths between myself and my next hop and want to distribute a data stream across them. Yes, those are important. The most common use of load balancing is most likely the use in data centers, where I decide that (to pick but one example) a given HTTP GET is appropriate to one set of servers and a different one, perhaps within the same pipelined TCP session, is appropriate to a different one, and multiplex the session across these sets of servers as appropriate. If you look up the class of products referred to as "load balancers", you will find them in those and similar applications. There are a number of other uses, but they are typified by that use case. If I want a random hash, I can - and do, and have since before the Internet was a commercial network - already generate that, by hashing the pseudoheader (actually just the source and destination address) of a stream of datagrams. That means that I don't have to remember which flow label I sent on one path and which I sent on another. If you want to tell me "oh, I take the modulus of the flow label with the number of servers I have to select which server", or any similar stateless algorithm, I can do it with that hash just as easily. And yes, that gives me a session predictably going to the same server. But it doesn't allow me to balance loads. To balance loads, I need to estimate the load on individual paths, and assign new data streams to paths as they change in their actual loading. What having the network be in control of the flow label does is allow the network to balance loads. Which is what you were trying to do, wasn't it? -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
