Subject: Re: [dhcwg] Discussion on draft-ietf-dhc-failover-12.txt

From: "David W. Hankins" <[email-masked]>
Date: Mon, 14 Feb 2005 16:17:36 -0800

First, I'd like to thank both Ted and Bernie for taking the time out of
their days to help me with this.  It's much appreciated, guys.

On Fri, Jan 28, 2005 at 07:30:11PM -0500, Bernie Volz wrote:
> If you have servers that are actively leasing, they'll almost ALWAYS be out
> of sync with each other. It takes time to send and process binding updates,
> especially if bulking is being used.

I think I meant something like "pathologically out of sync".

I wasn't referring to a simple case of lazy update at that point.

From Ted:
> Just a quick note - this can and frequently does happen if the two
> servers get behind in processing BNDUPD messages.   I think we've tuned
> a lot of this out of our server, but it's a real problem, and I don't
> think it can be completely tuned away.   So it really is something that
> needs to be accounted for.

And Bernie again I think saying the same thing:
> Depending on your rate of leasing activity and the size of the subnets
> you're using, this may or may not be an issue. But, if the rate is high or
> the subnets are small, this can be significant.
> 
> Each server can easily keep track of the "FREE" and "BACKUP" lease counts,
> but any calculations done on those are suspect because the server only has
> an accurate count of its leases -- not its partner's.

I've run this through my head several times, and I still don't see it.

Every time servers are behind on processing BNDUPDs or BNDACKs, their
idea of the number of leases they own is always less than their idea
of the number of leases their partner owns.  This will lead them to sending
POOLREQs (or in ISC's present implementation, multiples of them ahead of
any queued BNDUPDs so as to put them off even longer), but it never leads
to either of them actually allocating each other any leases, unless at
least enough synchronization has happened that it's clear that leases
should move.

But I did finally think of a scenario where the described events could
possibly cause bad things to happen.  If the servers are counting leases
that they themselves queued a BNDUPD for and had not yet received a BNDACK
as still belonging to themselves.  Is this the situation you are referring
to?

This argument just serves to make lease stealing look all the more wrong
to me.  If the primary believes it has fewer leases than the secondary,
which we can almost guarantee when behind on processing BNDUPD/BNDACK,
then it will steal some to regain its sense of balance.  It may even steal
all of the secondary's leases away, and then have to rebalance again later
down the road.

> In the various servers I've been involved with, we have done dynamic
> rebalancing by doing these calculations and moving leases. And, it always
> did a relatively good job. This isn't a violation of the failover protocol.
> But depending on how aggressive this rebalancing is and when it is done,
> POOLREQ are still useful.

I'm still not convinced.

POOLREQ doesn't impart any information to the peer that the peer doesn't
already know...it only creates an event, one which we hope that the
other server is already capable of sensing.  POOLRESP does impart some
information that the other server doesn't already know - but it's ueseless.
A good implementation certainly wouldn't use it to correct its sense of
balance.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg