headers
Hesham Soliman | 1 Mar 2012 01:53

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

>
>
>> >Basically a browser would pick a random 20-bit number when opening a
>> >page and would assign this 20-bit random number to all outgoing
>> >connections
>> >to the same site, whether they're HTTP or HTTPS btw.
>> 
>> 
>> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP
>> addresses? 
>
>I'd say it differently. It's safe to rely on anything but the IP address.

=> No one suggested that you rely on the address alone.

>One user != one IP address. It's only an approximation which is valid
>enough where it's only used for optimization, but not where user session
>stickiness is required.

=> And the flow label can ensure that stickiness by itself? That's a
contradiction of what you're trying to do.
If you want proper stickiness then you need unique application
identifiers. If you think the user's IP address is not stable enough and
you want stronger stickiness then I'd say the flow label is much worse.
More below

>For instance, hashing a source IP address is fine
>to load-balance an SSL farm, because most of the users will remain on the
>same SSL endpoint, and the small part of those who will constantly change
>will just experience a minor degradation which is not a show stopper. But
(Continue reading)

Permalink | Reply | 26 comments |
headers
Brian E Carpenter | 1 Mar 2012 04:07
Picon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

Hesham,

On 2012-03-01 13:53, Hesham Soliman wrote:
>>
>>>> Basically a browser would pick a random 20-bit number when opening a
>>>> page and would assign this 20-bit random number to all outgoing
>>>> connections
>>>> to the same site, whether they're HTTP or HTTPS btw.
>>>
>>> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP
>>> addresses? 
>> I'd say it differently. It's safe to rely on anything but the IP address.
> 
> => No one suggested that you rely on the address alone.
> 
>> One user != one IP address. It's only an approximation which is valid
>> enough where it's only used for optimization, but not where user session
>> stickiness is required.
> 
> => And the flow label can ensure that stickiness by itself? That's a
> contradiction of what you're trying to do.
> If you want proper stickiness then you need unique application
> identifiers. If you think the user's IP address is not stable enough and
> you want stronger stickiness then I'd say the flow label is much worse.
> More below
> 
>> For instance, hashing a source IP address is fine
>> to load-balance an SSL farm, because most of the users will remain on the
>> same SSL endpoint, and the small part of those who will constantly change
>> will just experience a minor degradation which is not a show stopper. But
(Continue reading)

Permalink | Reply | 25 comments |
headers
Willy Tarreau | 1 Mar 2012 07:40
Picon
Favicon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

On Wed, Feb 29, 2012 at 05:13:21PM -0500, Warren Kumari wrote:
> > This is totally pointless because the goal of "persistence" or "stickiness"
> > in load balancing precisely is to ensure that some form of user controlled
> > data is used to find the proper server. If you want to bring a random server
> > down, that's very easy. Just connect to it first, and feed the cookie to a
> > botnet which will always connect to the same server.
> 
> Um, not really -- this only applies if you use cookies for stickiness (and
> are load-balancing something like HTTP that uses cookies!)

Let me clarify. Stickiness is the opposite of load balancing. Load balancing
applies an algorithm and stickiness is the principle which consists in
finding the information which lets you pick the correct server without
applying the load balancing algorithm. In HTTP, cookie-based stickiness
precisely does that. Same for the RDP cookies used in TSE or with the
SSL-ID in SSL which is assigned by the server and works exactly like a
cookie.

Some hash-based load balancing algorithms are an alternative to the
combination of LB + stickiness. The principle is that if the information
is always present including the first time, then it is worth hashing to
find the appropriate server. This includes MAC/IP/ports where stickiness
is not critical (eg: etherchannel in switches, any stateless TCP-based
offloader, etc...), URLs for HTTP when caches are involved, username for
POP/IMAP servers, etc...

> There are a large number of other load balancing algorithms and a large
> number of protocols that don't have anything approaching a cookie...

I perfectly agree. What I meant is that there are a huge number of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Willy Tarreau | 1 Mar 2012 08:05
Picon
Favicon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

Hi Brian,

On Thu, Mar 01, 2012 at 04:07:57PM +1300, Brian E Carpenter wrote:
> > => Ok, but my point is that you can't compare flow labels and cookies
> > because you'll end up with either incorrect load distribution (because the
> > flow label doesn't tell you enough about the connection, or with users
> > being distributed onto different servers, depending on which side your
> > load distribution algorithm favours. What am I missing?
> 
> As the draft explains, you don't use the flow label to take the
> initial decision about which server gets which new session. That
> must be done by looking at much more of the first packet, exactly
> as today. You use the flow label to accelerate treatment of the
> subsequent packets. Please tell us where in the draft we need
> to make this more clear.

I have talked about that in this thread. In fact, I'm fairly certain that
once everyone will observe that flow labels follow an almost uniform
distribution, it will be safe to hash them in low level components such
as switches. Many switches are already able to hash MAC or IP addresses
right now. In a datacenter full of two-port servers, MAC addresses are
very poorly distributed, and nobody complains about the risk to cause an
unbalanced distribution on etherchannels. Same for IP addresses where .0
and .255 are almost never seen. But I agree that right now we should focus
only on load balancers learning the flow label and not on hashing.

> You do accept the 1 in 2^20 chance that two unrelated sessions have the
> same flow label; in that case they will need to be redirected to the same
> server. In any case the LB is going to need a hash table to look up current
> flow labels, but it certainly contains a monstrous hash table today for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel jaeggli | 1 Mar 2012 09:36

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

On 2/29/12 19:07 , Brian E Carpenter wrote:

>>
>> => Yes but they don't use flow labels for that. They use a unique
>> application-specific identifier.
>> flow label != cookie. The cookie is not created by the client.
> 
> Correct, and it's a fairly horrible solution, isn't it? It forces
> you into DPI for every packet in order to recognise the session.
> That's *exactly* what needs to change.

This is a fundamental misrepresentation of how load balancers work...

If you're doing l3+l4 there's nothing to "DPI" because you have to
dispatch a new TCP connection request on the basis of a SYN only,
there's literally nothing to inspect. If you are doing L7 termination,
for  example with http(s), imap or even sip there's no packet inspection
involved in plucking out a cookie, or login credentials or the like.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Permalink | Reply | 17 comments |
headers
Warren Kumari | 1 Mar 2012 16:02

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

Apologies for the top post -- this response isn't specific to this mail (and is more of a meta-comment), so I
am not responding inline...

My initial response to this draft was fairly negative -- I latched onto a shortcoming (mainly the fact that
the flow label is client generated) and didn't really give the whole idea the thought that it deserved -- I
apologize for this.

What occurs to me is that load-balancers support all sorts of algorithms and methods for mapping
(session|flow|stream-o-bits) to a backend. If this proposal / draft flies and gets adopted by the
vendors, I (and you) don't *have* to use it....
This will likely be implemented as yet another knob that can be enabled or disabled as inout to the decision
process -- if operators want to turn the knob on, who am I to say no? 
We all have different requirements, views, applications and traffic distributions -- I don't see a
downside to this idea, and it may have utility, so I officially withdraw my earlier grumpy face  :-)

W

On Feb 29, 2012, at 10:07 PM, Brian E Carpenter wrote:

> Hesham,
> 
> On 2012-03-01 13:53, Hesham Soliman wrote:
>>> 
>>>>> Basically a browser would pick a random 20-bit number when opening a
>>>>> page and would assign this 20-bit random number to all outgoing
>>>>> connections
>>>>> to the same site, whether they're HTTP or HTTPS btw.
>>>> 
>>>> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP
>>>> addresses?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Willy Tarreau | 1 Mar 2012 16:35
Picon
Favicon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

Hi Warren,

On Thu, Mar 01, 2012 at 10:02:05AM -0500, Warren Kumari wrote:
> Apologies for the top post -- this response isn't specific to this mail (and
> is more of a meta-comment), so I am not responding inline...
> 
> My initial response to this draft was fairly negative -- I latched onto a
> shortcoming (mainly the fact that the flow label is client generated) and
> didn't really give the whole idea the thought that it deserved -- I apologize
> for this.
> 
> What occurs to me is that load-balancers support all sorts of algorithms and
> methods for mapping (session|flow|stream-o-bits) to a backend. If this
> proposal / draft flies and gets adopted by the vendors, I (and you) don't
> *have* to use it....
> This will likely be implemented as yet another knob that can be enabled or
> disabled as inout to the decision process -- if operators want to turn the
> knob on, who am I to say no? 
> We all have different requirements, views, applications and traffic
> distributions -- I don't see a downside to this idea, and it may have
> utility, so I officially withdraw my earlier grumpy face  :-)

You're welcome, having people like you who ask for clarifying what
we wrote is extremely important because it forces us to structure our
ideas a bit more. The simple fact that people ask questions means we
need to clarify our explanations :-)

Regards,
Willy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 1 Mar 2012 21:01
Picon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

On 2012-03-01 21:36, Joel jaeggli wrote:
> On 2/29/12 19:07 , Brian E Carpenter wrote:
> 
>>> => Yes but they don't use flow labels for that. They use a unique
>>> application-specific identifier.
>>> flow label != cookie. The cookie is not created by the client.
>> Correct, and it's a fairly horrible solution, isn't it? It forces
>> you into DPI for every packet in order to recognise the session.
>> That's *exactly* what needs to change.
> 
> This is a fundamental misrepresentation of how load balancers work...
> 
> If you're doing l3+l4 there's nothing to "DPI" because you have to
> dispatch a new TCP connection request on the basis of a SYN only,
> there's literally nothing to inspect. If you are doing L7 termination,
> for  example with http(s), imap or even sip there's no packet inspection
> involved in plucking out a cookie, or login credentials or the like.

If you are mixing the two approaches, which I understand is common,
it isn't that simple. When you see a new L4 flow starting, you have to
check whether it is in fact part of an existing L7 flow but using
a different address/port.

I guess you are correct that once you have done this for the first full
L7 packet (not the SYN packet), you can revert to only looking at the
L3/L4 bits. But with IPv6 extension headers present, looking for L4
is extra work; the flow label is in a fixed place in the L3 header.

   Brian
(Continue reading)

Permalink | Reply | 16 comments |
headers
Hesham Soliman | 2 Mar 2012 01:26

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

Thanks for the clarification Brian. I feel more comfortable with those
answers below and I'm glad you're not relying on the flow label to make
the initial decision, which makes it better.

One other minor comment to make, I noticed, at least on email, references
to "browsers" setting the flow label. I'm going to be a bit picky and say
that we are really talking about (in the case of HTTP anyway) the HTTP lib
picking the flow label. Browsers are just one of the many apps that use
http nowadays and the less we rely on the app developers the more likely
we are to get something behaving uniformly.

Hesham

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@...>
Organization: University of Auckland
Date: Thu, 01 Mar 2012 16:07:57 +1300
To: Hesham Soliman <hesham@...>
Cc: Willy Tarreau <w <at> 1wt.eu>, IPv6 Operations <v6ops@...>
Subject: Re: [v6ops] So nobody cares about load balancers? [
draft-carpenter-v6ops-label-balance-01.txt]

>Hesham,
>
>On 2012-03-01 13:53, Hesham Soliman wrote:
>>>
>>>>> Basically a browser would pick a random 20-bit number when opening a
>>>>> page and would assign this 20-bit random number to all outgoing
>>>>> connections
>>>>> to the same site, whether they're HTTP or HTTPS btw.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Willy Tarreau | 2 Mar 2012 02:08
Picon
Favicon

Re: So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt]

On Fri, Mar 02, 2012 at 11:26:56AM +1100, Hesham Soliman wrote:
> Thanks for the clarification Brian. I feel more comfortable with those
> answers below and I'm glad you're not relying on the flow label to make
> the initial decision, which makes it better.
> 
> One other minor comment to make, I noticed, at least on email, references
> to "browsers" setting the flow label. I'm going to be a bit picky and say
> that we are really talking about (in the case of HTTP anyway) the HTTP lib
> picking the flow label. Browsers are just one of the many apps that use
> http nowadays and the less we rely on the app developers the more likely
> we are to get something behaving uniformly.

You're perfectly right Hesham. I did personally use the term "browser" to
illustrate what I meant but the process should happen at a lower layer,
ideally in the lib handling the sockets. I've been thinking about using a
couple of getsockopt() + setsockopt() to retrieve and set the flow label
on a connection, so that's definitely where it ought to be.

Regards,
Willy

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Permalink | Reply | 2 comments |

Gmane