A data center load balancer can afford, by its nature, to do as much
work as it needs to in order to get the information it needs.
The same can not be said for the ECMP / LAG case which Brian, Shane,
Steve, and I have been talking about.
Specifically, with the structure of extension headers, the possible use
of crypto, and the use of tunnels (and probably other issues), it
becomes more and more difficult for network devices along the path which
need to perofrm ECMP or LAG (L3 or L2 sleection among equivalent paths)
while keeping flows together, to do their job.
By getting the flow label used in a way that carries enough information,
this problem can become MUCH simpler.
None of your concerns seem to relate to the this problem.
In particular, I see no issue of network side control for this.
Yours,
Joel
On 1/10/2011 12:55 AM, Fred Baker wrote:
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
