Subject: Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Dec 2012 15:31:30 +0000

On Nov 21, 2012, at 3:53 PM, Ted Lemon <[email-masked]> wrote:
> Andre has asked if the working group would be willing to adopt his load balancing draft as a working group work item.   There's already been some discussion on the mailing list, but we haven't formally taken on the work.    The draft is here: http://tools.ietf.org/html/draft-kostur-dhc-loadbv6-03

Two people responded in favor of this call for adoption.   Nobody responded against.   If that's the total interest in the work, I think we don't have consensus to adopt.   If you just forgot to reply, please do so now, or else we'll drop this at least until some real demand surfaces.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 10 Dec 2012 15:42:20 +0000

Sorry I missed this call as I was on vacation at the time.

I do support adopting it. (So that makes 3 ...)

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, December 10, 2012 10:32 AM
To: [email-masked] WG
Subject: Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 10 Dec 2012 15:43:44 +0000

+1 (So that makes 4 ...)

Regards,
Gaurav
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, December 10, 2012 9:12 PM
To: Ted Lemon; [email-masked] WG
Subject: Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6

- Bernie

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 10 Dec 2012 11:18:23 -0500

I support adopting it as well. (So that makes 5 ...)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2012 14:05:04 +0000

> Two people responded in favor of this call for adoption.   Nobody responded against.   If that's the total interest in the work, I think we don't have consensus to adopt.   If you just forgot to re…

We now have a total of five people who've weighed in in favor of adopting this work.   There's nobody against it, but five in favor is a pretty weak consensus.   Are any of you all planning to implement this?   Why is this work needed?

---

From: perl-list <[email-masked]>
Date: Wed, 12 Dec 2012 09:09:44 -0500 (EST)

Isn't this redundant to the failover document that is already adopted? Doesn't that document provide a mechanism for deciding which server should answer requests? 

----- Original Message -----

> From: "Ted Lemon" <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Sent: Wednesday, December 12, 2012 9:05:04 AM

> > Two people responded in favor of this call for adoption. Nobody
> > responded against. If that's the total interest in the work, I
> > think we don't have consensus to adopt. If you just forgot to
> > reply, please do so now, or else we'll drop this at least until
> > some real demand surfaces.

> We now have a total of five people who've weighed in in favor of
> adopting this work. There's nobody against it, but five in favor is
> a pretty weak consensus. Are any of you all planning to implement
> this? Why is this work needed?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2012 14:36:05 +0000

> Isn't this redundant to the failover document that is already adopted?  Doesn't that document provide a mechanism for deciding which server should answer requests?

No, this document first of all is useful even if failover isn't in the picture—you can use it to set up two independent servers that share the load of serving a particular set of networks.   Second, load balancing is declared specifically out of scope in section 3.2 of the failover design document.

---

From: perl-list <[email-masked]>
Date: Wed, 12 Dec 2012 09:42:53 -0500 (EST)

hmmm... seems like we need load balancing if we are to have failover... unless people plan to not load balance as we did in DHCPv4 ... I support this document then. 
----- Original Message -----

> To: "perl-list" <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Wednesday, December 12, 2012 9:36:05 AM

> > Isn't this redundant to the failover document that is already
> > adopted? Doesn't that document provide a mechanism for deciding
> > which server should answer requests?

> No, this document first of all is useful even if failover isn't in
> the picture—you can use it to set up two independent servers that
> share the load of serving a particular set of networks. Second, load
> balancing is declared specifically out of scope in section 3.2 of
> the failover design document.

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 12 Dec 2012 15:46:10 +0100

One could ask if the decision to not have load balancing in the failover 
paper is still valid?
It could seem that load balancing comes first and as an option failover?

On 12/12/12 15:42, perl-list wrote:
> hmmm... seems like we need load balancing if we are to have 
> failover...  unless people plan to not load balance as we did in 
> DHCPv4 ... I support this document then.
>
> ------------------------------------------------------------------------
>
>     *From: *"Ted Lemon" <[email-masked]>
>     *To: *"perl-list" <[email-masked]>
>     *Cc: *"[email-masked] WG" <[email-masked]>
>     *Sent: *Wednesday, December 12, 2012 9:36:05 AM
>     *Subject: *Re: [dhcwg] Call for adoption: draft-kostur-dhc-loadbv6
>
>     the picture---you can use it to set up two independent servers
>     that share the load of serving a particular set of networks.  
>     Second, load balancing is declared specifically out of scope in
>     section 3.2 of the failover design document.
>
>
>
>
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

        "MALE BOVINE MANURE!!!"

---

From: perl-list <[email-masked]>
Date: Wed, 12 Dec 2012 10:03:50 -0500 (EST)

I could see failover without load balancing, but no load balancing without failover ( unnecessary ) ... the original RFC allows for one or more DHCPv6 servers and the client decides which one to use... or at least that is my understanding ... I have been wrong many times :) 
----- Original Message -----

> From: "Sten Carlsen" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, December 12, 2012 9:46:10 AM

> One could ask if the decision to not have load balancing in the
> failover paper is still valid?

> > dhcwg mailing list [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2012 15:05:41 +0000

On Dec 12, 2012, at 9:46 AM, Sten Carlsen <[email-masked]> wrote:
> One could ask if the decision to not have load balancing in the failover paper is still valid?

When we did DHCPv4 failover I argued in favor of this exact point.   However, in retrospect I'm not sure my argument was correct.   The problem is that failover with load balancing actually doesn't reduce server load: both servers still have to process all the leases, either directly or as binding updates.   So you get a bunch of added complexity with no performance payoff.    You _only_ get the performance payoff with two independent DHCP servers doing load balancing.   Which is actually a very practical configuration in DHCPv6, because address scarcity is so much less of a problem.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Dec 2012 07:32:43 -0800

> When we did DHCPv4 failover I argued in favor of this exact point.   However, in retrospect I'm not sure my argument was correct.   The problem is that failover with load balancing actually doesn't…

We are going to implement it, and there is server load reduction in a
load balancing case.  If your DHCP server is doing some heavy lifting
when considering incoming requests, the load balanced partner only has
to decide that it won't answer the request vs the "primary" partner
which has to do the expensive stuff (consult external systems,
perhaps?).  In our internal testing, it did increase the total
throughput of the DHCP system when comparing a single DHCP server vs.
a load balanced pair.

--
Andre Kostur

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 13 Dec 2012 14:36:26 +0100

I support this work as well (so that makes 6...)

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 13 Dec 2012 14:59:06 +0100

> One could ask if the decision to not have load balancing in the failover
Yes, and it is even more valid than before. We tried what we could to
make it as short as possible, but the current design draft is over 50
pages already (still an improvement to v4 draft that was 130+ pages).
There was no a single review since it was published over a month ago. So
yes - our initial assumption that it will be difficult to proceed,
simply because of its size was and still is correct.

Now having said that, we want to have failover to cover load balancing,
just not in the base draft. We have clearly stated that it will likely
be defined as an extension (see section 3.2 in
draft-ietf-dhc-dhcpv6-failover-design-02).

We even did more than just wishing to have it defined. Several states in
current state machine are really useful only when running in load
balancing (active-active) mode. We decided to keep them to make the
addition of LB easier. There is no text in failover drafts to highlight
that, because this would just confuse the reader. However, one of our
goals was to keep state machines for active-passive and active-active
modes exactly the same. My understanding of the states machines is that
we achieved that goal.

Also, we would welcome any authors that would like to start working on
the load balancing+failover draft. Due to other commitments I can't
start this work at this time, but I'm willing to help as a co-author. My
personal plan is to try to finish failover design draft and then start
working on failover on-wire spec. If the 3315bis work is not started in
the meantime, I'll work on LB+failover once requirements, design and
on-wire spec are done.

> It could seem that load balancing comes first and as an option failover?
It depends on what your goals are. If you don't need lease stability, go
for load balancing. If you need lease stability, failover is the way to
go (or tricks explained in redundancy-considerations, but some of them
are a bit scary).

There's also a somewhat philosophical question about load balancing and
failover. By definition each failover partner must be able to handle
100% traffic in case of its partner crash. So the typical reason for
deploying load balancing here (my server is not able to handle whole
traffic, so let's have two of them) will only give you false illusion of
safety. And this will bite you in the worst possible moment - when there
is a failure in your network and you expect failover to save the day.

Speaking of the failover, did anyone had a chance to review
draft-ietf-dhc-dhcpv6-failover-design-02? I would be very grateful for
any comments or suggestions, especially what to take away from it to
make it easier to read?

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 21:48:16 +0000

> We now have a total of five people who've weighed in in favor of adopting this work.   There's nobody against it, but five in favor is a pretty weak consensus.   Are any of you all planning to impl…

Okay, after sending this out several more people responded that they support the work, so I think we can adopt it as a working group document.   Andre, can you submit a working group document with any changes that you have waiting (if any)?

---

From: Bud Millwood <[email-masked]>
Date: Fri, 14 Dec 2012 17:33:15 +0100

> throughput of the DHCP system when comparing a single DHCP server vs.

Complicated subject.

We can parse about 2k packets per second, but only run about 200
transactions/s per engine thread, so avoiding the transaction really
makes a difference as far as the ability of two servers to process an
inbound load. That said, I think Ted meant that with failover, you're
replicating bindings sideways between servers, so each server has to
stuff the other's bindings into its storage, which means you end up
with the same database I/O rate as if you didn't have load balancing.

However... if sideways replication with your failover system requires
less overhead than processing the same lease as a transaction in the
DHCP in the engine, then load balancing with failover is a win.

Another thing to consider is the regularity of the inbound load. If it
varies over time, lazy-update failover may help to even out the
resource usage on each system by deferring part of the storage I/O
load to a later point in time.

- Bud