Subject: Failover Protocol versus SCSP

From: Tim Salo <[email-masked]>
Date: Tue, 4 May 1999 16:24:52 -0400 (EDT)

As I skim the current discussion of the DHCP failover protocol, the
possible use of TCP and mention of BGP, I again whether anyone
can provide me a concise answer to:

	Why is the DHCP working group developing another server-to-
	server synchronization protocol rather than using an existing
	protocol such as SCSP?

It seems that it would be useful develop an answer to this question
now, rather than when the question is asked during the IETF last call.

By the way, SCSP is modeled on BGP, which appears to be a model for
at least some working group members.

-tjs

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 4 May 1999 18:09:12 -0400 (EDT)

> at least some working group members.

This is not to make any judgement on suitability of SCSP for DCHP server
syncronization, but...

Wrt "SCSP is modeled on BGP", this is a fairly high level point of view.
Please also note that at high enough level we all look like a collection 
of atoms.

Yakov.
~

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 May 1999 00:03:32 -0400 (EDT)

> 	server synchronization protocol rather than using an existing

Because SCSP is horribly complicated and not particularly closely
related to the actual problem.  Just because two problems can be
called "database synchronization" doesn't mean they're the same
problem.  This idea was visited in great detail several years ago, and
the result was that forward progress was prevented until the idea was
finally abandoned.  What we have now is forward progress.  We are
absolutely not going to use SCSP for the current failover protocol.

			       _MelloN_

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 5 May 1999 11:30:58 -0400 (EDT)

>absolutely not going to use SCSP for the current failover protocol.

I completely agree with Ted.

To elaborate, there are two reasons that I think SCSP is not appropriate for 
the DHCP Failover protocol:

1. The DHCP failover protocol exploits various characteristics of the DHCP 
protocol in order to meet its design goals, and in so doing it becomes 
difficult to model it as a traditional cache synchronization problem.

2. Bob Cole and I did precisely what you suggest -- we wrote a draft where a 
DHCP interserver protocol was layered on SCSP. It handled 16 peer systems 
and was not strictly a failover protocol, but many of the key ideas in the 
failover protocol were also in the interserver protocol.  I looked around 
and can't find it anymore on a publically accessible web site, but I'll be 
glad to send the 90 page draft to anyone who is interested.  If any of you 
actually read it all the way through you'll be among a select few.
I seriously doubt that 5 people other than Bob Cole and I have ever read the 
draft -- judging from the deafening silence that resulted after submission.  
But say the word and I'll be glad to send it to you.

Cheers -- Kim

---

From: Rob Stevens <[email-masked]>
Date: Wed, 5 May 1999 13:51:27 -0400 (EDT)

>absolutely not going to use SCSP for the current failover protocol.

I agree with this comment of Ted's. To use SCSP is to ignore
certain features of the nature of the data which simplifies the problem
because not all the data has to be consistent all the time and with
very low latency. That's the feature that Kim and others have exploited
to produce a simplified solution. SCSP seems to me to be very,
very complicated.

However, I'm bound to say (and I've been meaning to bring this up
for some time) that my opinion about server-server is that absent
some form of DHCP load balancing that it may not really be worthwhile.

The people who are going to be really interested in a server to server
protocol are large fail-safe organisations, who are likely (if they
are wise) to have failover hardware. Therefore who needs a software
solution *unless* it can be coupled with load balancing?

Rob.

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 5 May 1999 15:00:25 -0400 (EDT)

At 01:51 PM 5/5/99 -0400, Rob Stevens wrote:
..
>solution *unless* it can be coupled with load balancing?

	One result of the failover meeting we held here
	in Chelmsford in February was a fairly neat
	approach to load balancing, where the percentage
	of the load can be configured (in a fairly
	broad and statistical way) between the primary
	and secondary servers.

	This will be represented in the next version
	of the failover draft, and is also discussed
	in more detail in the minutes of the meeting,
	which I thought were on the dhcp.org site,
	but which I can't find there.  If you want them,
	let me know and I'll send them to you.

	Cheers -- Kim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 May 1999 15:03:32 -0400 (EDT)

> some form of DHCP load balancing that it may not really be worthwhile.

We actually came up with a way to do load balancing at the interim
meeting, and I believe that it will be in the next draft.

> solution *unless* it can be coupled with load balancing?

Not really true.   I get interest in failover from people with <100
DHCP clients.   Reliability matters to everybody.

			       _MelloN_

---

From: "Robert G. Cole" <[email-masked]>
Date: Thu, 6 May 1999 15:36:53 -0400 (EDT)

I spent more time than I should have looking at Interserver on SCSP.  I
agree with Kim's assessment (and can dig up the draft if Kim can't). 

To add to Kim's comments, I think the biggest failure in trying to run
interserver over SCSP is that interserver REQUIRES tight synchronization of
address bindings whereas SCSP supports loose synchronization of database
records.
Hence there is a mismatch of capabilities/requirements.

Bob

>Date: Wed, 5 May 1999 11:36:52 -0400 (EDT)
>Reply-To: [email-masked]
>Originator: [email-masked]
>Sender: [email-masked]
>From: Kim Kinnear <[email-masked]>
>To: Multiple recipients of list <[email-masked]>
>Subject: Re: Failover Protocol versus SCSP 
>X-Comment: Discussion of DHCP for IPv4
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>
>
AT&T

330 St. Johns Street, 2nd Floor
Havre de Grace, MD
		21078

[email-masked]
+1 410 939-8732

---

From: Tim Salo <[email-masked]>
Date: Fri, 7 May 1999 12:37:22 -0400 (EDT)

> To: [email-masked]
> Date: Tue, 04 May 1999 23:30:50 -0400
> From: Ted Lemon <[email-masked]>
> 
> Because SCSP is horribly complicated...

There may be some truth in this.  A couple of thoughts:

o	I am not sure how relevant the complexity of SCSP itself is.
	It seems like the relevant question is: Is the interface
	SCSP provides to its applications, such as a distributed
	DHCP, too complex?

o	SCSP implementations are now becoming available.  I assume
	that a distributed DHCP server would use an existing
	implementation.

o	The FreeBSD SCSP implementation is 13,000 lines of code,
	including comments and perhaps 1,300 lines of debug code.
	(Again, I don't know what qualifies as "complex", and whether
	it is measured in lines of code or impenetrability of the spec.

> ... and not particularly closely related to the actual problem.
> Just because two problems can be
> problem.

One of my original questions was: Does the SCSP application interface
meet the needs of DHCP?  If not, what changes would be necessary to
the SCSP application interface to make the interface useful to DHCP?
(And, is it really worth the effort?)  We lost interest before we
could answer this question.

> This idea was visited in great detail several years ago, and
> finally abandoned.  What we have now is forward progress.

As I looked at the versions of the failover drafts, I was unable to
determine how much of the simplification resulted from not using SCSP and
how much resulted from eliminating many of the original requirements,
(i.e., 1 backup server rather than 16 servers).

(We originally got interested in this when we had contact with an
organization that wanted tens or perhaps a few hundred servers.  I
believe this problem is being solved through the use of lots of
proxies and perhaps a proprietary solution to a small number of 
distributed servers.)

> We are

This I believe, (although I am probably thinking about solving different
problems than are addressed by the current spec.)

-tjs

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 May 1999 13:41:42 -0400 (EDT)

Is your motivation here to improve SCSP, because you think it *ought*
to be able to be a solution for DHCP and you think that if it isn't
that's something you need to fix?  If so, it might be worth delving
into this further (indeed, I believe Kim's message to you previously
does delve further into this, whereas I will freely admit that my
"complexity" argument is essentially a gut reaction).

If you are just wondering why we don't move in that direction for the
benefit of DHCP, the answer is essentially that we don't believe the
protocol as it exists is a very good match with the problem of a DHCP
interserver protocol, and we don't want to burn any more of our
limited time on it.

			       _MelloN_