Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Apr 2006 21:07:00 -0300
From:      Patrick Tracanelli <eksffa@freebsdbrasil.com.br>
To:        AT Matik <asstec@matik.com.br>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: Load-balancing
Message-ID:  <443D9624.4010407@freebsdbrasil.com.br>
In-Reply-To: <200604121942.25737.asstec@matik.com.br>
References:  <20060411092932.42148fd8@giboia> <20060412214619.GT9364@elvis.mu.org> <443D7B71.5070004@freebsdbrasil.com.br> <200604121942.25737.asstec@matik.com.br>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
AT Matik wrote:
> On Wednesday 12 April 2006 19:13, Patrick Tracanelli wrote:
> 
>>Also, what about some sort of algorith more similar to "plr" for "prob"
>>action? As my understanding prob is really a probability, which does not
>>mean say 33% of the packets will match (while plr says it will match -
>>and drop the packet), it means 33% of probability, right? This would be
>>different of 33% of matching rate. Lets think of a "rate" option for
>>"matching rate", a
>>
> 
> 
> "probably" not a good choice to generate packet-loss when trying kind of load 
> balance
> 
> prob generates random rate (fwd in this case)
> plr generates random packet _loss_ rate 
> 
> I think the latter option create artificial kind of bw limit
> 
> Joćo

Tt is certainly the deal, according to the code as I mentioned in the 
later message. This is why a "rate" option would do this job better than 
prob which make use of random().

Anyway according to my tests this random() approach gets very close to a 
percentage. From more elaborated to simple tests such as:

# ipfw add 1 prob 0.33 deny icmp from me to any out icmptypes 8
# ping 10.69.69.1
[.. and there ping(1) goes...]
--- 10.69.69.1 ping statistics ---
28 packets transmitted, 18 packets received, 35% packet loss
round-trip min/avg/max/stddev = 0.229/0.280/0.359/0.036 ms

One can easily find out we get really close to the desired behaviour, 
except that the order it happens is really random (which means that with 
a small amount of tests, say, fewer packets, one might have distorted 
results).

So I believe the lack of a "fwd keep-state"-like behavior is more 
significant than the rate-with-precision stuff, when the matter is 
balancing...

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
316601@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?443D9624.4010407>