On 2011-01-10 18:42, Fred Baker wrote:
> On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote:
>
>> I'm confused. We've been talking for months about
>> recommending pseudo-random flow label values as inputs to
>> hash functions, precisely to allow scaleable and stateless
>> load balancing and ECMP.
>>
>> I completely agree that per-flow state doesn't scale.
>
> This isn't exactly the first time I have made the statement.
> I've been on record on this point regarding the flow label
> since it was designed to answer NIMROD's definition of a
> flow.
That is a long time ago, and actually the origin is even older
(as noted in draft-hu-flow-label-cases). But anyway, I don't
think we're disagreeing on this point.
On 2011-01-10 18:55, 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.
Sure, and I think the approach in draft-ietf-6man-flow-ecmp
would work there too.
>
> 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.
You don't need to remember anything in the stateless
draft-ietf-6man-flow-ecmp model.
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.
Why is that better than a statistical approach? I assume we're
talking about thousands of flows. In any case, in massive
server farms, the server load may be a more important parameter
than the network path load.
>
> 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?
Well, have you read the fine detail of the current draft
(today's version will do fine)? The intent is to provide
a default mechanism but to recognize the reality that we cannot
prevent network domains doing otherwise. That's what we authors
understood to be the WG rough consensus after multiple drafts.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
