Suggested change to TAKEOVER procedure

Johnson Walter-CWJ002 <[email protected]> Fri, 8 Jul 2005 16:27:16 -0500
Newsgroups gmane.ietf.rserpool
Message-ID <6F8DFFA2C996D711945800065BFC9E4A16048356@il02exm11>
It seems that if a peer registrar failed most of the peers if not all would send an ENRP_PRESENCE message after peer.last.heard expired for the failed peer. It seems as if the takeover procedure as defined would unfairly load the registrar with the largest registrar identifier since this registrar will always win the arbitration contest. In this case, the registrar with the largest identifier would/could naturally become overloaded with PEs through no fault of its own. Also, it seems there would naturally be a burst of traffic on the RSerPool network from all peer registrars when peer.last.heard expired trying to takeover the failed peer. 

 

As a potential solution, a registrar could generate a new 32 bit random number which is included for every ENRP_INIT_TAKEOVER message a sent. Since this would be arbitrary as opposed to a fix value (identifier) the potential PE loading on any arbitrary registrar would be more uniformly distributed. Also we were thinking this number could be used in the generation a backoff time for sending the ENRP_INIT_TAKEOVER message from each peer to avoid the flurry of traffic around the expiration of the peer.last.heard timer. Using this idea, the peer registrars in all likelihood would never send an ENRP_INIT_TAKEOVER messages since they most likely would receive a ENRP_INIT_TAKEOVER from the registrar that generated the highest random number and would simple mark the server as inactive and arbitration would rarely be needed and avoided. If needed, it would still exist. In addition, we now would h
 ave a random number as first comparison check for arbitration and the registrar identifie!
 rs as a second line of defense for breaking ties. 

 

This is even more conservative than the current approach.

 

What do people think?

 

Thanks

Walter

_______________________________________________
rserpool mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rserpool