Re: [courier-users] MX randomizing: trying to understand thesources.

Gordon Messmer wrote:

> Rodrigo Severo wrote:

>
> To use the example you provided later:
>
>> Let's see this example:
>>
>> 10 brsmtp02.br.abnamro.com
>> 10 brsmtp04.br.abnamro.com
>> 15 naxpf001.abnamro.com
>> 15 naxpf002.abnamro.com
>> 15 naxpf003.abnamro.com
>> 15 naxpf011.abnamro.com
>> 15 naxpf012.abnamro.com
>> 15 naxpf013.abnamro.com
>> 30 plum03ap.abnamro.com
>> 30 walnut001ap.abnamro.com
>>
>> In this case brsmtp02.br.abnamro.com has 9 out of 10 chances of being
>> contacted and brsmtp04.br.abnamro.com have the remaining 1 out of 10
>> chances. If we are using bind as DNS cache.
>
>
> That shouldn't be the case at all. The priority 15 hosts probably
> illustrate bind 9's strategy best. If bind 9 is choosing a random
> first entry, then it should choose naxpf001 about 16% of the time. It
> will be followed by naxpf002, etc, to the end of the list. On
> subsequent queries, each host will be as likely as any other to be the
> first item in the list, so naxpf001 might be selected. It would be
> followed by naxpf012, etc, through naxpf003.

I will try to explain this another way.

As far as I can tell, bind randomization gives each MX a 10% chance of
being the first one in the list. Up to now we have a good enough
distribution.

Then Courier gets these answers and discards all MXs except the top
priority ones without changing the order they were originally received.
This seems ok as Courier is only interested in the top priority ones.

The problem is that when he does that it ends 9 out of 10 times with
brsmtp02.br.abnamro.com before brsmtp04.br.abnamro.com which means
Courier will try to contact brsmtp02.br.abnamro.com most of the times in
case of a temporary delivery failure.

If my arguments don't convince you, please try it at a bind DNS cache.
Query it several times for these MXs. See which MX server Courier will
try to contact receiving each answer. Just remember that Courier is only
interested in the top priority MXs (priority 10 in this case). It might
be easier to spot the problem this way. I have done it.

> This is a totally reasonable randomness strategy. It provides
> suitable randomness for simple round-robin host selection, and should
> never give 90% priority to anything. Its implementation is highly
> performant, and very simple, which are respectable design decisions.

I agree completely. It isn't bind randomness strategy per si that
creates the distortion. Nor is Courier's MX choosing strategy either.
It's the *interaction* of bind randomness strategy and Courier MX
choosing strategy that produces the distortion.

I hope I made myself clearer now.


Thanks again for your attention and considerations,

Rodrigo Severo



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users