From dhcp-v4@bucknell.edu Mon May 3 11:16:45 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19461 for ; Mon, 3 May 1999 11:16:39 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA31410; Mon, 3 May 1999 11:06:36 -0400 (EDT) Date: Mon, 3 May 1999 11:06:36 -0400 (EDT) Message-Id: <00dc01be9574$f5121320$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi, At the last failover () meeting we were discussing how to use TCP for this protocol. Here is a portion of the notes from that meeting. (the full notes of the meeting in dhcp-serve@bucknell.edu group 3/99) > We agreed to try to see if we could figure out during the rest of > the meeting how to properly use TCP for this protocol. > > When discussing that, we determined that polling would be a problem > in TCP. We considered doing just the polls in UDP. > We agreed to do just the polls in UDP. Why? > 1. because if the TCP connection is busy, you can't necessarily > tell if the other server is up or not > 2. because if the TCP connection may not determine that the > other server is not up quickly enough > At the very end of the meeting, Ted suggested that we try to do > polls in TCP as well, and just accept that either up or down > detection was going to be spotty. We talked about it a bit, but > time was short. We did not agree to this approach, but did agree > that it merited further discussion. He agreed to raise this on the > list for further discussion. I propose that we could get rid of UDP completely, and just rely on TCP. I am sure that I have missed some fine points, so if somebody could point out any faults that would be appreciated. Here is what I propose: It is essentially based on the idea that we reset the partner connection timeout counter every time we receive any data from the partner; whether we receive a ping, or actual data. I think that this approach is valid because we should be getting all of the latest information from the other server before we start serving its addresses. So if the connection were to go down, then we would still like to get all of the information from the pipe before continuing. We will need two levels of polling. We can swap which one is responsible for initiating which polling, it makes no difference. --------------- A. 1. The primary's timer (period of T) goes off, sends a ping (P1) asking if the secondary is up. 2. Upon receipt of this ping P1, the secondary sends a reply to the primary (P1r). The secondary also resets its timer for not having heard from the primary. 3. The primary receives the secondary's response P1r, and resets its timer. It will send another ping P1 when this timer (T) has run out. If the primary does not receive the reply P1r after a certain lets say (X x T)...it will drop the connection, and proceed as if the secondary is down. --------------- --------------- B. Now this level of polling is to handle the case where the primary has buffered a lot of updates to be sent to the secondary, and the secondary has been processing this information for a long period of time, greater than the ping timeout time. If the primary puts a ping request on the queue of information for the secondary to process, then it will not receive it in time...this was a major concern when we were talking at the Failover meeting earlier this year. 1. The secondary has another timer (T2) that is reset every time it receives a ping P1 from the primary, or it sends data to the primary. It has a timeout period (Y x T), where ( 1 < Y < X ). It also has 2 flags, one if it has seen data (DATA) since T2 last popped, the other if T2 has popped, (POP). 2. If we receive information from the primary, that is not P1: if( POP ) //if the timer has popped { send( primary, P2r ) //send the primary the ping reset( T2r, DATA, POP ) //reset our timer } else { //timer has not popped DATA = true //set our flag to true } 3. If the timer (T2) pops: if( DATA ) //if we have received data { send( primary, P2r ) //send the primary our ping reset( T2r, DATA, POP ) //reset our timer } else { POP = true // set timer flag to true } 4. If the primary receives a T2r (inform ping from secondary), it should behave as normal and reset its T timer. -------------- I think that this addresses the problems raised at the failover meeting: > We agreed to do just the polls in UDP. Why? > 1. because if the TCP connection is busy, you can't necessarily > tell if the other server is up or not If the TCP connection is busy, that is fine, that is exactly what the plan B above takes care of. If it receives information it will send out an inform ping. > 2. because if the TCP connection may not determine that the > other server is not up quickly enough If you want speed, then just set the timeout values differently. I think that this would be up to the implementation to decide what priority to process events. I don't think that this is an issue with the above plan. -Dave ------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Mon May 3 13:38:55 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27558 for ; Mon, 3 May 1999 13:38:54 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA25587; Mon, 3 May 1999 13:31:14 -0400 (EDT) Date: Mon, 3 May 1999 13:31:14 -0400 (EDT) Message-Id: <000201be958b$45c3b880$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >I propose that we could get rid of UDP completely, and just rely on TCP. I would agree that UDP is not necessary in this protocol. BGP provides a good example of how many of the issues can be dealt with effectively in a TCP-based protocol. >Here is what I propose: >It is essentially based on the idea that we reset the partner connection >timeout counter every time we receive any data from the partner; whether we >receive a ping, or actual data. Yup. The BGP hold time is defined as the maximum time that may elapse between KEEPALIVE or UPDATE messages. Note that in BGP the hold time is negotiated to the lower of the values of the peers; the minimum recommended hold time is 3 seconds. >I think this approach is valid It is indeed valid, as demonstrated by the success of BGP. >If the primary puts a ping request on the queue of >information for the secondary to process, then it will >not receive it in time...this was a major concern when >we were talking at the Failover meeting earlier this >year. Since the connection can be kept open by either a keepalive or an update message, keeping the connection alive per se is not really an issue. However, there may be a desire to ensure latency bounds for certain high priority messages. The solution to this problem is to keep the size of the update messages small so that there will not be excessive latency. For example, if you have a 9600 bps link, serialization time for a 1500 octet packet is 1563 ms. So a critical message stuck behind a 1500 octet update could be delayed by that much, in addition to its own serialization, transit, and queuing delays. The solution is to have smaller update messages. In practice if the update unit is kept to the info involved in a single lease, then the latency should be acceptable less unless very severe congestion is encountered. Note that I use 9600 bps as an example link speed because almost all connections will be faster, and congestion would need to be very severe to push the effective rate below this. > We agreed to do just the polls in UDP. Why? > 1. because if the TCP connection is busy, you can't necessarily > tell if the other server is up or not If receipt of either a keepalive or update message is sufficient to provide information on whether the server is up then this should not be a concern. > 2. because if the TCP connection may not determine that the > other server is not up quickly enough I think that the issue here is congestive backoff. On congested links, the latency will increase as TCP backs off. Since this occurs due to dropped packets or increased RTT, there is a good reason for it, namely that the network cannot really support a higher rate. In such situations, the question should be asked as to how the UDP-based failover protocol would perform under the same circumstances. As long as the latency does not get so high that the hold time can't be maintained, I think that TCP will perform satisfactorily. If the latency is higher than that, then network conditions are likely to challenge UDP as well. Note that DHCP failover traffic is mission critical so that it probably makes sense to ensure that it receives appropriate QoS (i.e. low drop preference). From dhcp-v4@bucknell.edu Mon May 3 13:40:35 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27579 for ; Mon, 3 May 1999 13:40:32 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA03096; Mon, 3 May 1999 13:34:41 -0400 (EDT) Date: Mon, 3 May 1999 13:34:41 -0400 (EDT) Message-Id: <63D30D6E10CFD11190A90000F805FE86011070C7@lespaul.process.com> Errors-To: droms@bucknell.edu Reply-To: Gonczi@process.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Steve Gonczi To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; X-Mailer: Internet Mail Service (5.0.1460.8) Mime-Version: 1.0 Dave, We have retained UDP in order to provide an "instant" out-of-band messaging channel. This is not so easy to do with TCP. sG -----Original Message----- From: David Erdmann [mailto:derdmann@nortelnetworks.com] Sent: Monday, May 03, 1999 11:12 AM To: Multiple recipients of list Subject: DHCP failover--using only TCP (no UDP polling) Hi, At the last failover () meeting we were discussing how to use TCP for this protocol. Here is a portion of the notes from that meeting. (the full notes of the meeting in dhcp-serve@bucknell.edu group 3/99) > We agreed to try to see if we could figure out during the rest of > the meeting how to properly use TCP for this protocol. > > When discussing that, we determined that polling would be a problem > in TCP. We considered doing just the polls in UDP. > We agreed to do just the polls in UDP. Why? > 1. because if the TCP connection is busy, you can't necessarily > tell if the other server is up or not > 2. because if the TCP connection may not determine that the > other server is not up quickly enough > At the very end of the meeting, Ted suggested that we try to do > polls in TCP as well, and just accept that either up or down > detection was going to be spotty. We talked about it a bit, but > time was short. We did not agree to this approach, but did agree > that it merited further discussion. He agreed to raise this on the > list for further discussion. I propose that we could get rid of UDP completely, and just rely on TCP. I am sure that I have missed some fine points, so if somebody could point out any faults that would be appreciated. Here is what I propose: It is essentially based on the idea that we reset the partner connection timeout counter every time we receive any data from the partner; whether we receive a ping, or actual data. I think that this approach is valid because we should be getting all of the latest information from the other server before we start serving its addresses. So if the connection were to go down, then we would still like to get all of the information from the pipe before continuing. We will need two levels of polling. We can swap which one is responsible for initiating which polling, it makes no difference. --------------- A. 1. The primary's timer (period of T) goes off, sends a ping (P1) asking if the secondary is up. 2. Upon receipt of this ping P1, the secondary sends a reply to the primary (P1r). The secondary also resets its timer for not having heard from the primary. 3. The primary receives the secondary's response P1r, and resets its timer. It will send another ping P1 when this timer (T) has run out. If the primary does not receive the reply P1r after a certain lets say (X x T)...it will drop the connection, and proceed as if the secondary is down. --------------- --------------- B. Now this level of polling is to handle the case where the primary has buffered a lot of updates to be sent to the secondary, and the secondary has been processing this information for a long period of time, greater than the ping timeout time. If the primary puts a ping request on the queue of information for the secondary to process, then it will not receive it in time...this was a major concern when we were talking at the Failover meeting earlier this year. 1. The secondary has another timer (T2) that is reset every time it receives a ping P1 from the primary, or it sends data to the primary. It has a timeout period (Y x T), where ( 1 < Y < X ). It also has 2 flags, one if it has seen data (DATA) since T2 last popped, the other if T2 has popped, (POP). 2. If we receive information from the primary, that is not P1: if( POP ) //if the timer has popped { send( primary, P2r ) //send the primary the ping reset( T2r, DATA, POP ) //reset our timer } else { //timer has not popped DATA = true //set our flag to true } 3. If the timer (T2) pops: if( DATA ) //if we have received data { send( primary, P2r ) //send the primary our ping reset( T2r, DATA, POP ) //reset our timer } else { POP = true // set timer flag to true } 4. If the primary receives a T2r (inform ping from secondary), it should behave as normal and reset its T timer. -------------- I think that this addresses the problems raised at the failover meeting: > We agreed to do just the polls in UDP. Why? > 1. because if the TCP connection is busy, you can't necessarily > tell if the other server is up or not If the TCP connection is busy, that is fine, that is exactly what the plan B above takes care of. If it receives information it will send out an inform ping. > 2. because if the TCP connection may not determine that the > other server is not up quickly enough If you want speed, then just set the timeout values differently. I think that this would be up to the implementation to decide what priority to process events. I don't think that this is an issue with the above plan. -Dave ------------- Dave Erdmann Nortel Networks, NetID Group mailto:derdmann@nortelnetworks.com From dhcp-v4@bucknell.edu Mon May 3 14:35:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29007 for ; Mon, 3 May 1999 14:35:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA31204; Mon, 3 May 1999 14:27:24 -0400 (EDT) Date: Mon, 3 May 1999 14:27:24 -0400 (EDT) Message-Id: <00e801be958d$37eb08b0$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Steve, I do not immediately see the need for the out-of-band messaging. What messages do you think we would need to pass that have to be out of band? The only out-of-band traffic that I can think of would be state transition of the partner. Under what circumstances would it be necessary to have out of bound communication? -Dave > > Dave, > > We have retained UDP in order to provide an "instant" out-of-band > messaging > channel. > This is not so easy to do with TCP. > > sG > > -----Original Message----- > From: David Erdmann [mailto:derdmann@nortelnetworks.com] > Sent: Monday, May 03, 1999 11:12 AM > To: Multiple recipients of list > Subject: DHCP failover--using only TCP (no UDP polling) > > > Hi, > > At the last failover () meeting we were discussing how to use TCP for this > protocol. Here is a portion of the notes from that meeting. > (the full notes of the meeting in dhcp-serve@bucknell.edu group 3/99) > > > We agreed to try to see if we could figure out during the rest of > > the meeting how to properly use TCP for this protocol. > > > > When discussing that, we determined that polling would be a problem > > in TCP. We considered doing just the polls in UDP. > > > We agreed to do just the polls in UDP. Why? > > > 1. because if the TCP connection is busy, you can't necessarily > > tell if the other server is up or not > > > 2. because if the TCP connection may not determine that the > > other server is not up quickly enough > > > At the very end of the meeting, Ted suggested that we try to do > > polls in TCP as well, and just accept that either up or down > > detection was going to be spotty. We talked about it a bit, but > > time was short. We did not agree to this approach, but did agree > > that it merited further discussion. He agreed to raise this on the > > list for further discussion. > > I propose that we could get rid of UDP completely, and just rely on TCP. > I am sure that I have missed some fine points, so if somebody could > point out any faults that would be appreciated. > > Here is what I propose: > > It is essentially based on the idea that we reset the partner connection > timeout counter every time we receive any data from the partner; > whether we > receive a ping, or actual data. > > I think that this approach is valid because we should be getting > all of the > latest > information from the other server before we start serving its addresses. > So if the connection were to go down, then we would still like to get all > of the information from the pipe before continuing. > > > We will need two levels of polling. We can swap which one is responsible > for initiating which polling, it makes no difference. > > --------------- > A. > 1. The primary's timer (period of T) goes off, sends a ping (P1) asking if > the secondary is up. > 2. Upon receipt of this ping P1, the secondary sends a reply to > the primary > (P1r). > The secondary also resets its timer for not having heard from the > primary. > 3. The primary receives the secondary's response P1r, and resets > its timer. > It will send another ping P1 when this timer (T) has run out. > If the primary does not receive the reply P1r after a certain lets > say (X x T)...it will drop the connection, and proceed as if the > secondary is down. > --------------- > > --------------- > B. > Now this level of polling is to handle the case where the primary has > buffered > a lot of updates to be sent to the secondary, and the secondary has been > processing this information for a long period of time, greater > than the ping > timeout time. If the primary puts a ping request on the queue of > information > for the secondary to process, then it will not receive it in > time...this was > a > major concern when we were talking at the Failover meeting earlier this > year. > > 1. The secondary has another timer (T2) that is reset every time > it receives > a > ping P1 from the primary, or it sends data to the primary. It has a > timeout > period (Y x T), where ( 1 < Y < X ). > It also has 2 flags, one if it has seen data (DATA) since T2 last > popped, > the other if T2 has popped, (POP). > > 2. If we receive information from the primary, that is not P1: > if( POP ) //if the timer has popped > { > send( primary, P2r ) //send the primary the ping > reset( T2r, DATA, POP ) //reset our timer > } else { //timer has not popped > DATA = true //set our flag to true > } > > 3. If the timer (T2) pops: > if( DATA ) //if we have received data > { > send( primary, P2r ) //send the primary our ping > reset( T2r, DATA, POP ) //reset our timer > } else { > POP = true // set timer flag to true > } > > 4. If the primary receives a T2r (inform ping from secondary), > it should behave as normal and reset its T timer. > -------------- > > I think that this addresses the problems raised at the failover meeting: > > > We agreed to do just the polls in UDP. Why? > > 1. because if the TCP connection is busy, you can't necessarily > > tell if the other server is up or not > > If the TCP connection is busy, that is fine, that is exactly what the plan > B above takes care of. If it receives information it will send out an > inform > ping. > > > 2. because if the TCP connection may not determine that the > > other server is not up quickly enough > > If you want speed, then just set the timeout values differently. > I think that this would be up to the implementation to decide > what priority > to process events. I don't think that this is an issue with the > above plan. > > > -Dave > > ------------- > Dave Erdmann > Nortel Networks, NetID Group > mailto:derdmann@nortelnetworks.com > From dhcp-v4@bucknell.edu Mon May 3 14:36:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29061 for ; Mon, 3 May 1999 14:35:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA22731; Mon, 3 May 1999 14:26:31 -0400 (EDT) Date: Mon, 3 May 1999 14:26:31 -0400 (EDT) Message-Id: <372DE163.1E61BDD3@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > >I propose that we could get rid of UDP completely, and just rely on > >TCP. > > I would agree that UDP is not necessary in this protocol. I'm not so sure that this is a great idea. I think that the DHCP group should be leading the effort to multicast-enable as many protocols as possible, and this one seems like a good candidate. Multicasting would provide a lot of functionality to a replication protocol, allowing multiple backups to handle multiple primaries easier than a TCP-based transaction would allow (it would of course provide a lot of functionality to DHCP in general, something that I would like to see more time and effort spent on discussing). Going to TCP exclusively will preclude the use of IP multicasts. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Mon May 3 15:20:00 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01643 for ; Mon, 3 May 1999 15:19:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA30658; Mon, 3 May 1999 15:12:34 -0400 (EDT) Date: Mon, 3 May 1999 15:12:34 -0400 (EDT) Message-Id: <00e901be9596$174d5690$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > > >I propose that we could get rid of UDP completely, and just rely on > > >TCP. > > > > I would agree that UDP is not necessary in this protocol. > > Eric Hall wrote: > > I'm not so sure that this is a great idea. I think that the DHCP group > should be leading the effort to multicast-enable as many protocols as > possible, and this one seems like a good candidate. Multicasting would > provide a lot of functionality to a replication protocol, allowing > multiple backups to handle multiple primaries easier than a TCP-based > transaction would allow (it would of course provide a lot of > functionality to DHCP in general, something that I would like to see > more time and effort spent on discussing). > > Going to TCP exclusively will preclude the use of IP multicasts. Eric, If by referring to multiple backups handling multiple primaries, you implying that multiple backups can be desginated for a single primary, then that is not the current aim of this failover protocol. I thought that we were looking for a single backup solution for this current draft, and that having multiple backups for a single primary would possibly the case for future different failover protocols. Using multicasts in a failover protocol that is trying to communicate between 1 primary and 1 backup does not make sense to me. I am not clear how multicasting only some of the traffic will help. I think that using multicasting for backing up a primary to multiple backups is definitly worth exploring however. -Dave From dhcp-v4@bucknell.edu Mon May 3 15:20:42 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01667 for ; Mon, 3 May 1999 15:20:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA18715; Mon, 3 May 1999 15:14:00 -0400 (EDT) Date: Mon, 3 May 1999 15:14:00 -0400 (EDT) Message-Id: <372DF25B.32F85A11@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > I think that using multicasting for backing up a primary to multiple > backups is definitly worth exploring however. My concern is that by "going to TCP" we will make it more difficult to implement multicasting later, simply because the entire process will have to be reinvented. This only increases the likelihood that it will not happen, IMHO. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Mon May 3 16:11:21 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03457 for ; Mon, 3 May 1999 16:11:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA20382; Mon, 3 May 1999 16:05:20 -0400 (EDT) Date: Mon, 3 May 1999 16:05:20 -0400 (EDT) Message-Id: <00ec01be959a$b07b5ed0$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Steve Gonczi wrote: > > Dave, > > We have retained UDP in order to provide an "instant" out-of-band > messaging > channel. > This is not so easy to do with TCP. > > sG > Steve, If we can determine that there is a need for this out of bound traffic then I agree that we should consider UDP. However I do not see why we need out of bound traffic. As a side note I think that from a design and implementation point of view that we should be trying to only use one protocol unless there are obvious and considerable advantages to using both. Consider the added complexity of having 2 protocols to deal with. Lets take security as an example. At some point we want to implement security over the communications between the two servers. Security (encryption, and authentication) is pretty hard to get right on 1 protocol let alone 2. I don't think that we have to look too far to see examples of programs in use on the net that have had security problems. I see using one less protocol as one less area for things to go wrong. -Dave From dhcp-v4@bucknell.edu Mon May 3 16:11:35 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03470 for ; Mon, 3 May 1999 16:11:28 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA13904; Mon, 3 May 1999 16:04:25 -0400 (EDT) Date: Mon, 3 May 1999 16:04:25 -0400 (EDT) Message-Id: <00eb01be9599$38aba320$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > >If the primary puts a ping request on the queue of > >information for the secondary to process, then it will > >not receive it in time...this was a major concern when > >we were talking at the Failover meeting earlier this > >year. > > Since the connection can be kept open by either a > keepalive or an update message, keeping the connection > alive per se is not really an issue. However, there may be > a desire to ensure latency bounds for certain high > priority messages. > I am not sure that there are any messages that need any guarantees as to latency bounds in this failover protocol. My understanding of the UDP messaging was that its' only purpose was to provide ping capabilites, while passing some additional information with the ping. > The solution to this problem is to keep the size of the > update messages small so that there will not be excessive > latency. For example, if you have a 9600 bps link, > serialization time for a 1500 octet packet is 1563 ms. > So a critical message stuck behind a 1500 octet update > could be delayed by that much, in addition to its > own serialization, transit, and queuing delays. > > The solution is to have smaller update messages. > In practice if the update unit is kept to the info > involved in a single lease, then the latency should > be acceptable less unless very severe congestion is > encountered. > I agree that by making smaller messages you will reduce latency of processing a single message, but I don't think that it will help in this case, and I don't think that we want to shrink our update messages any more. We have a base amount of information to pass. The whole problem revolves around the assumption that we have a lot of information in the TCP buffer. If we go and say that we want to reduce the size of each update, then I can equally come back and say that I want to increase the number of updates that I want to send. So in essence we still have the same amount of raw data buffered to be sent out, that is going to take a while. Plus if the receiving server is heavilly loaded from other connections, the bandwidth of the connection might not be the bottleneck. > > We agreed to do just the polls in UDP. Why? > > 1. because if the TCP connection is busy, you can't necessarily > > tell if the other server is up or not > > If receipt of either a keepalive or update message is > sufficient to provide information on whether the > server is up then this should not be a concern. This is a concern because if the Primary is sending a lot of data to the secondary, and the secondary has no information to send to the primary, and the primary is responsible for initiating a keepalive, then the primary will not be getting any information from the secondary. The primary will assume that the secondary is down, but the connection has not thrown an exception yet. -Dave From dhcp-v4@bucknell.edu Mon May 3 16:11:54 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03486 for ; Mon, 3 May 1999 16:11:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA20461; Mon, 3 May 1999 16:05:50 -0400 (EDT) Date: Mon, 3 May 1999 16:05:50 -0400 (EDT) Message-Id: <00ed01be959f$2c546660$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Eric Hall wrote: > > > > I think that using multicasting for backing up a primary to multiple > > backups is definitly worth exploring however. > > My concern is that by "going to TCP" we will make it more difficult to > implement multicasting later, simply because the entire process will > have to be reinvented. This only increases the likelihood that it will > not happen, IMHO. > Eric, That is a valid concern. So it sounds that you are saying that you would prefer to use UDP for the failover protocol, no TCP at all. It was my impression from the last failover meeting that we were going to go with TCP and UDP. My suggestion is to get rid of the UDP since we were only going to be sending keep-alive information over it along with some sync information. On the note of expandability to multiple backups for a single primary: I agree that it would be nice to make this protocol draft as easy as possible to expand upon as possible. It is not clear to me how creating a failover protocol that is dependent on TCP and UDP would be easier to expand upon than just TCP or UDP alone. I am not sure that the idea of future use of multicasting was presented during the decicion to go from all UDP to TCP/UDP in February. But do we want to layout how we want to do n level backups before we finish 1 level backups? I doubt it. -Dave From dhcp-v4@bucknell.edu Mon May 3 18:12:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09160 for ; Mon, 3 May 1999 18:12:31 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA16033; Mon, 3 May 1999 18:06:16 -0400 (EDT) Date: Mon, 3 May 1999 18:06:16 -0400 (EDT) Message-Id: <199905032202.SAA02577@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > My concern is that by "going to TCP" we will make it more difficult to > implement multicasting later, simply because the entire process will > have to be reinvented. This only increases the likelihood that it will > not happen, IMHO. The benefit of multicasting to the interserver protocol, even a fully-blown one, seems dubious. Since we are not implementing a more-than-two-way protocol here, it seems particularly dubious. I see no point in considering this issue in decisions about the failover protocol - if after having learned what we learn from the failover protocol, we decide that it's possible to implement an N-way protocol, the protocol is clearly going to change anyway, and we can consider moving to UDP+Multicast then. There is absolutely no need to be concerned about this now, since there can only ever be two peers in the failover protocol. _MelloN_ From dhcp-v4@bucknell.edu Mon May 3 20:01:21 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13500 for ; Mon, 3 May 1999 20:01:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA14376; Mon, 3 May 1999 19:54:46 -0400 (EDT) Date: Mon, 3 May 1999 19:54:46 -0400 (EDT) Message-Id: <199905032332.TAA00565@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: rwoundy@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rich Woundy To: Multiple recipients of list Subject: Re: dhcp + Authentication X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 My understanding of the RoadRunner cable system is that the computer device gets an IP address from DHCP *before* the login/authentication process is started. The login process disables traffic filters elsewhere in the cable system on a per-user basis. The login protocol appears to use a TCP connection to connect to an authentication server. -- Richard Woundy, Cisco Systems At 10:23 PM 4/30/99 -0400, William A. Arbaugh wrote: >Base DHCP authentication does not provide authentication, however, a draft >has been published (see Ralph Droms site www.dhcp.org). There are a few >issues that have been resolved but are not in the current draft. I hope to >publish a new draft within a few weeks. Please look at the current one and >ask any questions you like. > >As for RoadRunner, I have no idea what they are doing. I would like to >hear if anyone knows. > >Bill > >On Fri, 30 Apr 1999, Jim Greene wrote: > >> Hello Group... >> I have a question regarding the use of DHCP and authentication. >> Is there a way to make the client provide authentication information before >> dhcpd will give the client an IP address. Is there other ways to go about >> this. I know Road Runner and others do this. DO you have any idea how it >> is done ?. From reading over the dhcp RFC's there is nothing built in that >> I can see. ANy help would be appreciated A LOT >> >> Thanks >> >> Jim G >> >> > From dhcp-v4@bucknell.edu Tue May 4 02:22:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25821 for ; Tue, 4 May 1999 02:22:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA14968; Tue, 4 May 1999 02:14:27 -0400 (EDT) Date: Tue, 4 May 1999 02:14:27 -0400 (EDT) Message-Id: <000801be95f4$d5454c80$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >I am not sure that there are any messages that need any guarantees >as to latency bounds in this failover protocol. My understanding >of the UDP messaging was that its' only purpose was to provide >ping capabilites, while passing some additional information with the >ping. Keepalive messages running over TCP can also be used for this purpose. >We have a base amount of information to pass. The issue is really batched updates. If you can squeeze the keepalives in between the updates, then you can run them over TCP without an issue. Allowing large batches of updates will increase the jitter in keepalive arrivals and increase the probability that you will not be able to squeeze them in within the hold time, which could conceivably be quite short (i.e. BGP default hold time of 3 seconds). >Plus if the receiving server is heavily loaded from other >connections, the bandwidth of the connection >might not be the bottleneck. I am curious as to how what traffic levels are anticipated here. Are we talking about receiving servers that have high CPU loading or are experiencing high failover traffic levels? In either situation, we would probably see an effect on UDP as well as TCP. >This is a concern because if the Primary is sending a lot of data >to the secondary, and the secondary has no information to send to >the primary, and the primary is responsible for initiating a keepalive, >then the primary will not be getting any information from the >secondary. The primary will assume that the secondary is down, >but the connection has not thrown an exception yet. The solution to this is to send Keepalive messages in both directions. That way the secondary will be required to send at least one message within the hold time. From dhcp-v4@bucknell.edu Tue May 4 09:00:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29781 for ; Tue, 4 May 1999 09:00:55 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA25823; Tue, 4 May 1999 08:55:19 -0400 (EDT) Date: Tue, 4 May 1999 08:55:19 -0400 (EDT) Message-Id: <004e01be9629$a2eb2ea0$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >The benefit of multicasting to the interserver protocol, even a >fully-blown one, seems dubious. Since we are not implementing a >more-than-two-way protocol here, it seems particularly dubious. It should be noted that multicast only generates traffic reduction to the extent that traffic passes over the same path. This occurs at the expense of increased routing system state. In general, the benefits of multicast do not exceed the costs until substantial numbers of systems are involved. That isn't the case for this protocol, nor is it clear that this test would be met for successors. Moreover, given the kind of data that is being multicast, reliable multicast transport would probably be required. Solving that transport problem is a considerable problem in itself. IMHO, multicast is not something to worry about here. From dhcp-v4@bucknell.edu Tue May 4 09:05:32 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00149 for ; Tue, 4 May 1999 09:05:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA16601; Tue, 4 May 1999 09:02:01 -0400 (EDT) Date: Tue, 4 May 1999 09:02:01 -0400 (EDT) Message-Id: <004f01be962a$b74b22a0$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >As a side note I think that from a design and implementation point of >view that we should be trying to only use one protocol unless there >are obvious and considerable advantages to using both. Consider >the added complexity of having 2 protocols to deal with. In general, only a single protocol should be used unless there are very compelling reasons to the contrary, since using two protocols complicates deployment considerably. For example, use of both UDP and TCP will complicate firewall setup. It will also make securing the protocol more difficult. >This is a concern because if the Primary is sending a lot of data >to the secondary, and the secondary has no information to send to >the primary, and the primary is responsible for initiating a keepalive, >then the primary will not be getting any information from the >secondary. The primary will assume that the secondary is down, >but the connection has not thrown an exception yet. The solution to this is to send Keepalive messages in both directions. That way the secondary will be required to send at least one message within the hold time. From dhcp-v4@bucknell.edu Tue May 4 11:12:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08019 for ; Tue, 4 May 1999 11:12:35 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA24249; Tue, 4 May 1999 11:02:40 -0400 (EDT) Date: Tue, 4 May 1999 11:02:40 -0400 (EDT) Message-Id: <372F0537.2A583566@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > It should be noted that multicast only generates > traffic reduction to the extent that traffic passes > over the same path. I was thinking more about the one-to-many benefits of having a primary send a single instance of lease data to multiple (highly distributed) backups simultaneously. I wasn't thinking about utilization. > given the kind of data that is being multicast, > reliable multicast transport would probably be > required. Maybe. I don't know. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue May 4 13:13:11 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17788 for ; Tue, 4 May 1999 13:13:09 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA09883; Tue, 4 May 1999 13:05:40 -0400 (EDT) Date: Tue, 4 May 1999 13:05:40 -0400 (EDT) Message-Id: <372F229E.F4809725@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > If you aren't thinking about utilization, you probably shouldn't be > thinking about multicast. There are plenty of examples where multicasting's one-to-many feature is the primary focus, instead of utilization. NTP is one of these examples. NTP uses trivial amounts of bandwidth over the long haul. The real benefit to using multicasts with NTP is that you can replicate the time data to a widely distributed set of hosts using a single send, instead of having to maintain separate connections for all of the hosts. The same benefits of one-to-many could be realized here. (Side note, these would be benefits for DHCP in general: a client that sent a query to an mcast address would let any server anywhere on the network respond to the query, without having to depend on bootp forwarders.) > Even assuming that it would be possible to multicast the bulk of the > data, the reverse-channel acknowledgement and retry path would have > to be unicast. Effective multicasting depends on all systems being able to communicate via multicast. If the protocol requires acknowledgments go to a unicast address, then this protocol is not a good candidate for multicast. Read that however you like. My original position is still: making this TCP-based will only make it more difficult to do multicasting (and one-to-many replication) later. It would seem that the protocol is already transaction-centric, so perhaps it doesn't matter (if you're using application ACKs, then this protcol can't be used for multicasting anyway). -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Tue May 4 13:13:15 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17812 for ; Tue, 4 May 1999 13:13:12 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA17695; Tue, 4 May 1999 13:02:49 -0400 (EDT) Date: Tue, 4 May 1999 13:02:49 -0400 (EDT) Message-Id: <199905041624.MAA03217@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > I was thinking more about the one-to-many benefits of having a primary > send a single instance of lease data to multiple (highly distributed) > backups simultaneously. I wasn't thinking about utilization. If you aren't thinking about utilization, you probably shouldn't be thinking about multicast. > > given the kind of data that is being multicast, > > reliable multicast transport would probably be > > required. > > Maybe. I don't know. The current failover protocol does require reliable delivery of some messages in order to work properly. These messages are the ones that are involved with the highest traffic volume - the ones where you might conceivably benefit from using multicast. Even assuming that it would be possible to multicast the bulk of the data, the reverse-channel acknowledgement and retry path would have to be unicast. This would be hell to implement, so there should be a really strong reason to do it. _MelloN_ From dhcp-v4@bucknell.edu Tue May 4 13:38:03 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17789 for ; Tue, 4 May 1999 13:13:10 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA08575; Tue, 4 May 1999 13:06:03 -0400 (EDT) Date: Tue, 4 May 1999 13:06:03 -0400 (EDT) Message-Id: <000001be964f$79fe3c00$9b50fb8d@net-derdmann.corpnorth.baynetworks.com> Errors-To: droms@bucknell.edu Reply-To: derdmann@nortelnetworks.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "David Erdmann" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit > > The issue is really batched updates. If you can squeeze the > keepalives in between the updates, then you can run them > over TCP without an issue. Allowing large batches of updates > will increase the jitter in keepalive arrivals and increase > the probability that you will not be able to squeeze them > in within the hold time, which could conceivably be quite > short (i.e. BGP default hold time of 3 seconds). > How would you know how frequently to insert the messages? Since the rate of consumption of the buffered data is variable. > I am curious as to how what traffic levels are anticipated > here. Are we talking about receiving servers that have > high CPU loading or are experiencing high failover > traffic levels? In either situation, we would probably > see an effect on UDP as well as TCP. > It is conceivable that there could be a high CPU load, or lots of traffic on a NIC, coupled with high failover traffic. > >This is a concern because if the Primary is sending a lot of data > >to the secondary, and the secondary has no information to send to > >the primary, and the primary is responsible for initiating a keepalive, > >then the primary will not be getting any information from the > >secondary. The primary will assume that the secondary is down, > >but the connection has not thrown an exception yet. > > The solution to this is to send Keepalive messages in > both directions. That way the secondary will be required > to send at least one message within the hold time. > This would work. I like this. If we don't care about the query response, then we could just have the primary and secondary send the keepalive message at a given interval. From dhcp-v4@bucknell.edu Tue May 4 14:03:58 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21423 for ; Tue, 4 May 1999 14:03:57 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA06301; Tue, 4 May 1999 13:57:41 -0400 (EDT) Date: Tue, 4 May 1999 13:57:41 -0400 (EDT) Message-Id: <199905041721.NAA03436@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > The real benefit to using multicasts with NTP is that you can > replicate the time data to a widely distributed set of hosts using a > single send, instead of having to maintain separate connections for > all of the hosts. The same benefits of one-to-many could be realized > here. Nope. The servers would all have to know about each other. In the current protocol, both servers are fairly intimately aware of each other's state when they're in the "communicating" state. There's really no way to avoid that, no matter how clever the protocol gets. So this particular benefit is one benefit that we definitely would not get from multicast. > My original position is still: making this TCP-based will only make it > more difficult to do multicasting (and one-to-many replication) later. > It would seem that the protocol is already transaction-centric, so > perhaps it doesn't matter (if you're using application ACKs, then this > protcol can't be used for multicasting anyway). Right. Precisely. There are two different levels of ACKs in the UDP version of the failover protocol that AI/Cisco and Process Software have implemented. Even in the TCP protocol, there are still application-level ACKs. _MelloN_ From dhcp-v4@bucknell.edu Tue May 4 14:04:59 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21443 for ; Tue, 4 May 1999 14:04:58 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA25703; Tue, 4 May 1999 13:58:14 -0400 (EDT) Date: Tue, 4 May 1999 13:58:14 -0400 (EDT) Message-Id: <199905041738.NAA03506@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > How would you know how frequently to insert the messages? Since > the rate of consumption of the buffered data is variable. In order for the protocol to work over TCP, both ends need to promise the other end to consume data at a certain rate, and neither end can send data fast enough that a round-trip ping couldn't happen in the required minimum ping time. The data doesn't necessarily have to be processed, but it has to be taken out of the pipe so that a response can get through. The way this would work is that, for example, each side might promise the other to be able to buffer as many as 10 unacknowledged messages. Each side of course responds to pings immediately, since these presumably are cheap to process. So when a side has sent ten updates without receiving any application-layer acknowledgement, it stops sending updates until it gets an acknowledgement. It continues to send pings at the required interval, and the other side continues to respond to these immediately. > This would work. I like this. If we don't care about the query > response, then we could just have the primary and secondary send the > keepalive message at a given interval. We really need to be able to establish a bidirectional working path, and we need to be able to have fairly tight control over the ping packets, so I would say that keepalives don't meet this need very well. I think we talked about using them at the interim meeting and decided they wouldn't work, although I don't remember any more detail than that. _MelloN_ From dhcp-v4@bucknell.edu Tue May 4 15:14:14 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24112 for ; Tue, 4 May 1999 15:14:13 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA00158; Tue, 4 May 1999 15:09:34 -0400 (EDT) Date: Tue, 4 May 1999 15:09:34 -0400 (EDT) Message-Id: <199905041903.PAA08763@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 01:58 PM 5/4/99 -0400, Ted Lemon wrote: > >> How would you know how frequently to insert the messages? Since >> the rate of consumption of the buffered data is variable. > >In order for the protocol to work over TCP, both ends need to promise >the other end to consume data at a certain rate, and neither end can >send data fast enough that a round-trip ping couldn't happen in the >required minimum ping time. The data doesn't necessarily have to be >processed, but it has to be taken out of the pipe so that a response >can get through. The way this would work is that, for example, each >side might promise the other to be able to buffer as many as 10 >unacknowledged messages. Each side of course responds to pings >immediately, since these presumably are cheap to process. So when a >side has sent ten updates without receiving any application-layer >acknowledgement, it stops sending updates until it gets an >acknowledgement. It continues to send pings at the required >interval, and the other side continues to respond to these >immediately. Ted, that's astonishingly clearly stated. Wow. This is *exactly* what we do today with the UDP protocol in order to build in a primitive flow control so that one server does not swamp the other server with updates. Except in the UDP case, the receiving side has to take whatever the transmitting side gives it. It works quite well. But ... but .. but ... I thought that we were switching to TCP in part so that we didn't have re-invent flow control. Another reason was so we didn't have to do retrasmissions, and another reason was so that we didn't have out of order messages. (Says the soothing voice in the background.) If we need to do application level flow control in order to use just TCP so that we can avoid having to do retransmissions and avoid having to worry about out of order messages (which is no small thing, let me tell you), I can live with it. We also wanted to use UDP to establish some sort of time synchronization for those of us who wanted to support servers that don't have synchronized clocks. But I think we could do this with TCP as part of the server synchronization, though I've not worked out the details. If you all buy into Ted's approach for polls and application level flow control, I think it could work. > >> This would work. I like this. If we don't care about the query >> response, then we could just have the primary and secondary send the >> keepalive message at a given interval. > >We really need to be able to establish a bidirectional working path, >and we need to be able to have fairly tight control over the ping >packets, so I would say that keepalives don't meet this need very >well. I think we talked about using them at the interim meeting and >decided they wouldn't work, although I don't remember any more detail >than that. > > _MelloN_ > From dhcp-v4@bucknell.edu Tue May 4 15:14:37 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24128 for ; Tue, 4 May 1999 15:14:36 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA15303; Tue, 4 May 1999 15:09:10 -0400 (EDT) Date: Tue, 4 May 1999 15:09:10 -0400 (EDT) Message-Id: <199905041849.OAA08099@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 01:57 PM 5/4/99 -0400, Ted Lemon wrote: .. > >Right. Precisely. There are two different levels of ACKs in the >UDP version of the failover protocol that AI/Cisco and Process >Software have implemented. Even in the TCP protocol, there are still >application-level ACKs. > > _MelloN_ > Yes! The protocol absolutely requires an ACK from the server which receives a binding update, and that ACK indicates that the receiving server has written the binding update information to its stable storage (i.e., disk or database). From dhcp-v4@bucknell.edu Tue May 4 15:14:42 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24143 for ; Tue, 4 May 1999 15:14:42 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA31625; Tue, 4 May 1999 15:06:51 -0400 (EDT) Date: Tue, 4 May 1999 15:06:51 -0400 (EDT) Message-Id: <199905041846.OAA07969@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Dave, Thanks for starting this discussion. One first point, and then I'll respond to the included message. In the -03 protocol (the current draft), each server's idea of whether the other server is "up" or not is based on receipt of replies to its own poll messages. This is largely so that a half-duplex connection will not seem "up" to one server, and down to the other. It is clear that a round trip has occurred, which is essentially what is required for the protocol to work. The rest of my responses are inline, below: At 01:06 PM 5/4/99 -0400, David Erdmann wrote: >> I am curious as to how what traffic levels are anticipated >> here. Are we talking about receiving servers that have >> high CPU loading or are experiencing high failover >> traffic levels? In either situation, we would probably >> see an effect on UDP as well as TCP. >> > >It is conceivable that there could be a high CPU load, or lots >of traffic on a NIC, coupled with high failover traffic. It certainly is. There can be very high traffic on the DHCP client side of the server, as well as high traffic on the incoming failover connection. The failover connection traffic is lower priority than the DHCP client traffic, and so could be allowed to back up considerably in favor of processing the DHCP client traffic. > >> >This is a concern because if the Primary is sending a lot of data >> >to the secondary, and the secondary has no information to send to >> >the primary, and the primary is responsible for initiating a keepalive, >> >then the primary will not be getting any information from the >> >secondary. The primary will assume that the secondary is down, >> >but the connection has not thrown an exception yet. >> >> The solution to this is to send Keepalive messages in >> both directions. That way the secondary will be required >> to send at least one message within the hold time. I must be missing something (or more) -- if we do this, then what is the point of the keepalive message? Doesn't the receipt of data do just as much for you? If you don't care about round-trip integrity of the connection, then you can just use the existance of data in your input queue as an indication that the other server is up. (But I think we *do* care about the round-trip integrity of the connection.) >> > >This would work. I like this. If we don't care about the query >response, then we could just have the primary and secondary send the >keepalive message at a given interval. One major (and I think related) issue is where we do the buffering. If one were to drain the TCP queue with high priority, and then buffer all of the data inside of the server, then the TCP connection could be easily used for doing the polling work. But that seems to lose much of the value of the TCP connection, since you have to build some kind of flow control into the connection if you use it this way -- just like you do with a UDP connection. I think part of the value of the TCP connection is that you can just stuff information down it until it blocks on the sending side, and you can process it as you get to it on the receiving side, thus utilizing the natural flow control built into the protocol (instead of building our own on top of UDP). But if we use it this way, then we have this problem telling whether the other server is alive when that other server is really busy and not willing to process the messages with any kind of priority. In short, I can imagine (and I have seen) situations where one server can get so busy that it could hold off failover messages for 15 to 30 seconds or more, and process only one or two messages during that period. In the event that happens (and that isn't any sort of failure condition), then it is not all that unlikely that the connection could be considered to be "down" when in fact it is not -- if we send polls down the TCP connection like we do with UDP today. So, we need to devise a way that one server can hold off on processing another server's messages (for good and sufficient reasons), and yet still somehow indicate that it is *able* to processes those messages -- and that it will (in the fullness of time). Couple that with the need to bring both servers into communication (which yields its own little set of issues). I don't see that emitting keepalives on a regular schedule meets those needs. From dhcp-v4@bucknell.edu Tue May 4 16:32:27 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26400 for ; Tue, 4 May 1999 16:32:25 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA25568; Tue, 4 May 1999 16:24:52 -0400 (EDT) Date: Tue, 4 May 1999 16:24:52 -0400 (EDT) Message-Id: <199905042024.PAA79954@us.networkcs.com> Errors-To: droms@bucknell.edu Reply-To: salo@networkcs.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Tim Salo To: Multiple recipients of list Subject: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 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 dhcp-v4@bucknell.edu Tue May 4 18:16:16 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28309 for ; Tue, 4 May 1999 18:16:15 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA06801; Tue, 4 May 1999 18:09:12 -0400 (EDT) Date: Tue, 4 May 1999 18:09:12 -0400 (EDT) Message-Id: <199905042122.OAA04886@omega.cisco.com> Errors-To: droms@bucknell.edu Reply-To: yakov@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Yakov Rekhter To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 > 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. 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 dhcp-v4@bucknell.edu Wed May 5 00:08:25 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02623 for ; Wed, 5 May 1999 00:08:25 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA25861; Wed, 5 May 1999 00:03:32 -0400 (EDT) Date: Wed, 5 May 1999 00:03:32 -0400 (EDT) Message-Id: <199905050330.XAA04960@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 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? 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 dhcp-v4@bucknell.edu Wed May 5 11:38:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24793 for ; Wed, 5 May 1999 11:38:39 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA20631; Wed, 5 May 1999 11:30:58 -0400 (EDT) Date: Wed, 5 May 1999 11:30:58 -0400 (EDT) Message-Id: <199905051451.KAA15501@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 12:04 AM 5/5/99 -0400, Ted Lemon wrote: > >> 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? > >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_ > 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 dhcp-v4@bucknell.edu Wed May 5 12:49:12 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26166 for ; Wed, 5 May 1999 12:49:11 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA14575; Wed, 5 May 1999 12:42:59 -0400 (EDT) Date: Wed, 5 May 1999 12:42:59 -0400 (EDT) Message-Id: <00a501be970d$c91de060$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >> The solution to this is to send Keepalive messages in >> both directions. That way the secondary will be required >> to send at least one message within the hold time. >I must be missing something (or more) -- if we do >this, then what is the point of the keepalive message? >Doesn't the receipt of data do just as much for you? Yes. Receipt of either a keepalive or update message is sufficient to keep the connection up. The question was about a half-connection that had not received any update messages; how would you know that it was still alive? The proposed solution in that case would be to send a keepalive. With respect to scheduling of the keepalives so that the hold time is maintained, several implementation approaches are possible. One is to keep a timer that is reset whenever update messages go out and thus guarantees that a keepalive or update message is sent within the hold time interval. >If you don't care about round-trip integrity of the >connection, then you can just use the existance of >data in your input queue as an indication that the >other server is up. (But I think we *do* care about >the round-trip integrity of the connection.) As for "round trip integrity" I am curious as to how the definition of this differs from just having both half-connections up. Are you looking to derive an RTT estimate? >One major (and I think related) issue is where we >do the buffering... we have this problem telling whether >the other server is alive when that other server >is really busy and not willing to process the >messages with any kind of priority. This sounds like an implementation issue to me. If a bi-directional hold time were implemented, the implication would be that the application would need to take precautions to make sure that the hold time was maintained. A variety of scheduling algorithms can be implemented while accomodating this requirement. Strict priority isn't one of them, but "priority with at least X amount of keepalive traffic" would do. >So, we need to devise a way that one server can >hold off on processing another server's messages >(for good and sufficient reasons), and yet still >somehow indicate that it is *able* to processes >those messages -- and that it will (in the fullness >of time). Again, this seems like an implementation issue to me. The sending of keepalive messages does not necessarily need to block on emptying the receive buffer of update messages. From dhcp-v4@bucknell.edu Wed May 5 12:49:19 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26178 for ; Wed, 5 May 1999 12:49:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA20766; Wed, 5 May 1999 12:45:02 -0400 (EDT) Date: Wed, 5 May 1999 12:45:02 -0400 (EDT) Message-Id: <00a601be970e$8824c500$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >The protocol absolutely requires an ACK from the server which >receives a binding update, and that ACK indicates that the >receiving server has written the binding update information to >its stable storage (i.e., disk or database). This is what makes the implementation of this protocol using multicast anything but simple. You not only need to implement ACKs, you also probably need to make them reliable. The end result would be that a unicast UDP implementation would have very little in common with a multicast implementation, even though both would run over UDP. Remember, UDP is not really a transport layer -- it's a building block. The problem is hard enough without adding reliable multicast transport to the list of issues. From dhcp-v4@bucknell.edu Wed May 5 13:54:23 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27347 for ; Wed, 5 May 1999 13:54:22 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15867; Wed, 5 May 1999 13:51:27 -0400 (EDT) Date: Wed, 5 May 1999 13:51:27 -0400 (EDT) Message-Id: <4.1.19990505105616.00a3d620@mail.join.com> Errors-To: droms@bucknell.edu Reply-To: robs@join.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Rob Stevens To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 >> 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? > >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. > 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 dhcp-v4@bucknell.edu Wed May 5 13:54:46 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27360 for ; Wed, 5 May 1999 13:54:45 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA12212; Wed, 5 May 1999 13:51:49 -0400 (EDT) Date: Wed, 5 May 1999 13:51:49 -0400 (EDT) Message-Id: <37307C06.A5A56745@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > This is what makes the implementation of this protocol using > multicast anything but simple. You not only need to implement > ACKs, you also probably need to make them reliable. I have given up on trying to promote making this protocol multicast aware. It is obviously too difficult. I have not given up on pushing for a protocol that could use multicasts however. It would seem that replication could use multicasting quite easily, where updates were sent to the mcast address, and each member also sent out periodic state-markers or checksums or something, indicating the transactions they have seen and recorded. If any members are out-of-synch, they could initiate synchronization using unicasts (and get the benefits of TCP then). Actually, by having DHCP clients bind and send to a multicast address (instead of using 0.0.0.0 and bootp forwards), all of the lease data would be seen by all of the servers anyway, effectively providing replication for free. The biggest problem would come if the network suffered a meltdown and all of the members got out of synch, which could require a lot of synchronization work to recover from. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed May 5 13:57:50 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27410 for ; Wed, 5 May 1999 13:57:48 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15317; Wed, 5 May 1999 13:48:31 -0400 (EDT) Date: Wed, 5 May 1999 13:48:31 -0400 (EDT) Message-Id: <199905051706.NAA21749@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 12:45 PM 5/5/99 -0400, Bernard Aboba wrote: >>The protocol absolutely requires an ACK from the server which >>receives a binding update, and that ACK indicates that the >>receiving server has written the binding update information to >>its stable storage (i.e., disk or database). > >This is what makes the implementation of this protocol using >multicast anything but simple. You not only need to implement >ACKs, you also probably need to make them reliable. The end >result would be that a unicast UDP implementation would have >very little in common with a multicast implementation, even >though both would run over UDP. Remember, UDP is not really >a transport layer -- it's a building block. The problem is >hard enough without adding reliable multicast transport to >the list of issues. > I'm not excited about making the problem harder, yet while we're on this subject, I would observe that I don't *think* the ACK's have to be reliable, if I understand what we're all talking about here. I think the sub-topic we've been discussing here is the use of multicast for the distribution of binding updates. The details have been assumed. If we dig down a bit, then I think the primary would multicast the binding updates to a bunch of secondaries. I'm guessing that the best approach would be for the secondaries to unicast the ACK's back to the primary, but they too could be multicast. At some point, if the primary didn't get an ack from every secondary it might re-send the multicast or it might unicast to a specific secondary. At some point the primary/secondary distinction starts to disappear, and they all are multicasting updates and ACKs to everyone. I don't think any of this needs to be reliable, if one is willing to build the necessary retry logic into the server. Having built pretty much all of this in a primary-secondary scenario out of UDP, I can say that it isn't that difficult to do. So, I conclude (waving my hands) that reliable multicast isn't necessary. FWIW. Cheers -- Kim From dhcp-v4@bucknell.edu Wed May 5 15:05:02 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28440 for ; Wed, 5 May 1999 15:05:01 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA03113; Wed, 5 May 1999 14:58:19 -0400 (EDT) Date: Wed, 5 May 1999 14:58:19 -0400 (EDT) Message-Id: <37308602.DC874D5A@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > At some point the primary/secondary distinction > starts to disappear, and they all are multicasting > updates and ACKs to everyone. Yes! All servers would essentially be primaries, and the difference between a primary vs a secondary would only depend on how it was configured for a particular per-subnet. There would be no need for a difference in the actual traffic. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed May 5 15:05:05 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28452 for ; Wed, 5 May 1999 15:05:05 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA31657; Wed, 5 May 1999 15:02:35 -0400 (EDT) Date: Wed, 5 May 1999 15:02:35 -0400 (EDT) Message-Id: <3730926A.57DFFB95@ehsco.com> Errors-To: droms@bucknell.edu Reply-To: ehall@ehsco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Eric A. Hall" To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.5 [en] (WinNT; I) Content-Transfer-Encoding: 7bit > In addition to changing the broadcast behavior of > clients, you would also have to change the renewal > behavior since renews are unicast to the DHCP server > and ACK's are unicast back to the DHCP client by the > server. Yeah. Without thinking about this too hard, it would seem that the entire lease negotiation process (including the parts that are unicast today) would have to be done via multicast in order for other servers to be "witnesses" to the complete process. There are other challenges here. Eliminating bootp forwarders obviously has merit (I hate them), but they also provide data that is useful in the lease negotiation process today (subnet selection, for example). Maintaining backwards compatibility with bootp is an issue too. These are all resolvable though. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From dhcp-v4@bucknell.edu Wed May 5 15:05:10 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28465 for ; Wed, 5 May 1999 15:05:09 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA14662; Wed, 5 May 1999 14:59:43 -0400 (EDT) Date: Wed, 5 May 1999 14:59:43 -0400 (EDT) Message-Id: <199905051839.OAA26250@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 01:52 PM 5/5/99 -0400, Eric A. Hall wrote: > >> This is what makes the implementation of this protocol using >> multicast anything but simple. You not only need to implement >> ACKs, you also probably need to make them reliable. > >I have given up on trying to promote making this protocol multicast >aware. It is obviously too difficult. > .. >Actually, by having DHCP clients bind and send to a multicast address >(instead of using 0.0.0.0 and bootp forwards), all of the lease data >would be seen by all of the servers anyway, effectively providing >replication for free. An interesting approach. In addition to changing the broadcast behavior of clients, you would also have to change the renewal behavior since renews are unicast to the DHCP server and ACK's are unicast back to the DHCP client by the server. > >The biggest problem would come if the network suffered a meltdown and >all of the members got out of synch, which could require a lot of >synchronization work to recover from. > >-- >Eric A. Hall ehall@ehsco.com >+1-650-685-0557 http://www.ehsco.com > From dhcp-v4@bucknell.edu Wed May 5 15:05:35 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28481 for ; Wed, 5 May 1999 15:05:34 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA29652; Wed, 5 May 1999 15:00:25 -0400 (EDT) Date: Wed, 5 May 1999 15:00:25 -0400 (EDT) Message-Id: <199905051843.OAA26460@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 01:51 PM 5/5/99 -0400, Rob Stevens wrote: .. > >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. > 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 dhcp-v4@bucknell.edu Wed May 5 15:05:41 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28493 for ; Wed, 5 May 1999 15:05:40 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA05857; Wed, 5 May 1999 15:03:32 -0400 (EDT) Date: Wed, 5 May 1999 15:03:32 -0400 (EDT) Message-Id: <199905051854.OAA00669@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > 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. 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. > 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? Not really true. I get interest in failover from people with <100 DHCP clients. Reliability matters to everybody. _MelloN_ From dhcp-v4@bucknell.edu Thu May 6 04:14:36 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20027 for ; Thu, 6 May 1999 04:14:35 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA13270; Thu, 6 May 1999 04:07:53 -0400 (EDT) Date: Thu, 6 May 1999 04:07:53 -0400 (EDT) Message-Id: <00c601be9794$b5d2d600$268939cc@internaut.com> Errors-To: droms@bucknell.edu Reply-To: aboba@internaut.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Bernard Aboba" To: Multiple recipients of list Subject: RE: DHCP failover--using only TCP (no UDP polling) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit >I think the primary would multicast >the binding updates to a bunch of secondaries. I'm >guessing that the best approach would be for the >secondaries to unicast the ACKs back to the primary, >but they too could be multicast. At some point, >if the primary didn't get an ack from every secondary >it might re-send the multicast or it might unicast >to a specific secondary. The primary can certainly keep a membership list, track the ACKs and retransmit as required (most likely via unicast). However, some questions will arise: 1. Retransmit timers. To make sure that you weren't retransmitting too often, you'd probably need to compute an RTT estimate for the members. 2. Window advancement. A policy would be needed on when the next update could be sent in the absence of ACKs from all members. So you'd need to think about when the window was advanced, window sizing, etc. 3. Membership. This would include the policy for how a secondary joins the membership group, and under what conditions it is to be removed (number of retransmissions and/or time without an ACK). There is considerable research and knowledge that can be utilized in answering these questions so that the problem is by no means insolvable. However, when you're done answering the questions above, I'd wonder how much code you'd still have in common with the previous UDP implementation. In reliable multicast, the devil is in the details, and protocol often start off simple, only to gain in complexity as corner conditions are encountered. >So, I conclude (waving my hands) that reliable >multicast isn't necessary. FWIW. Actually, what you've just described is a variant of reliable multicast transport (albeit with unicast ACKing and retransmission). From dhcp-v4@bucknell.edu Thu May 6 10:43:22 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25900 for ; Thu, 6 May 1999 10:43:20 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA08136; Thu, 6 May 1999 10:35:29 -0400 (EDT) Date: Thu, 6 May 1999 10:35:29 -0400 (EDT) Message-Id: <199905061355.JAA28511@mail.bucknell.edu> Errors-To: droms@bucknell.edu Reply-To: droms@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ralph Droms To: Multiple recipients of list Subject: Re: Error Condition Re: SIADDR? X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 siaddr contains the IP address of a server willing to provide additional bootstrap information; e.g., an OS image to be downloaded via TFTP. - Ralph Droms At 09:48 AM 5/6/99 -0400, you wrote: > >message sent to dhcp-v4@bucknell.edu by JENS.KASSEL@UAB.ERICSSON.SE follows. >---------------------------------------------------------------------------- >Hello! > >RFC: 2131 Page: 9 >SIADDR : IP address of next server to use in bootstrap. > >What is next server to use in bootstrap? > >Please help me! > >Jens Kassel from Sweden > From dhcp-v4@bucknell.edu Thu May 6 15:42:31 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02491 for ; Thu, 6 May 1999 15:42:29 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA28280; Thu, 6 May 1999 15:36:53 -0400 (EDT) Date: Thu, 6 May 1999 15:36:53 -0400 (EDT) Message-Id: <3.0.6.32.19990506141340.0093a9d0@postoffice.worldnet.att.net> Errors-To: droms@bucknell.edu Reply-To: robertgcole@worldnet.att.net Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Robert G. Cole" To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) 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: kkinnear@cisco.com >Originator: dhcp-v4@bucknell.edu >Sender: dhcp-v4@bucknell.edu >From: Kim Kinnear >To: Multiple recipients of list >Subject: Re: Failover Protocol versus SCSP >X-Comment: Discussion of DHCP for IPv4 >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 > > >At 12:04 AM 5/5/99 -0400, Ted Lemon wrote: >> >>> 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? >> >>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_ >> > >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 > AT&T 330 St. Johns Street, 2nd Floor Havre de Grace, MD 21078 robertgcole@worldnet.att.net +1 410 939-8732 From dhcp-v4@bucknell.edu Fri May 7 12:45:17 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06775 for ; Fri, 7 May 1999 12:45:16 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA05036; Fri, 7 May 1999 12:37:22 -0400 (EDT) Date: Fri, 7 May 1999 12:37:22 -0400 (EDT) Message-Id: <199905071546.KAA41745@us.networkcs.com> Errors-To: droms@bucknell.edu Reply-To: salo@networkcs.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Tim Salo To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > To: salo@networkcs.com > Subject: Re: Failover Protocol versus SCSP > Date: Tue, 04 May 1999 23:30:50 -0400 > From: Ted Lemon > > > 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? > > 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 > called "database synchronization" doesn't mean they're the same > 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 > the result was that forward progress was prevented until the idea was > 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 > absolutely not going to use SCSP for the current failover protocol. This I believe, (although I am probably thinking about solving different problems than are addressed by the current spec.) -tjs From dhcp-v4@bucknell.edu Fri May 7 13:46:42 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08078 for ; Fri, 7 May 1999 13:46:41 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA13733; Fri, 7 May 1999 13:41:42 -0400 (EDT) Date: Fri, 7 May 1999 13:41:42 -0400 (EDT) Message-Id: <199905071659.MAA00771@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: Failover Protocol versus SCSP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 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_ From dhcp-v4@bucknell.edu Mon May 10 18:57:53 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11719 for ; Mon, 10 May 1999 18:57:53 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA22810; Mon, 10 May 1999 18:53:30 -0400 (EDT) Date: Mon, 10 May 1999 18:53:30 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: sam@incognito.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: (Sam Yee) To: Multiple recipients of list Subject: subscribe dhcp-v4 Sam Yee X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 subscribe dhcp-v4 Sam Yee From dhcp-v4@bucknell.edu Tue May 11 03:04:06 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22948 for ; Tue, 11 May 1999 03:04:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA01752; Tue, 11 May 1999 02:58:57 -0400 (EDT) Date: Tue, 11 May 1999 02:58:57 -0400 (EDT) Message-Id: <3737CC81.FF93B191@uab.ericsson.se> Errors-To: droms@bucknell.edu Reply-To: per.wadelius@uab.ericsson.se Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Per Wadelius To: Multiple recipients of list Subject: DHCP client behavior X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.04 [en] (Win95; I) Content-Transfer-Encoding: 7bit Hello! If a DHCP client is in INIT-REBOOT state and sends DHCPREQUEST and gets no DHCPACK or DHCPNAK. Is it correct for that client to use its previous address if it gets no answer from an ARP request. - Per Wadelius From dhcp-v4@bucknell.edu Tue May 11 03:05:17 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22974 for ; Tue, 11 May 1999 03:05:17 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id DAA32765; Tue, 11 May 1999 03:01:12 -0400 (EDT) Date: Tue, 11 May 1999 03:01:12 -0400 (EDT) Message-Id: <19990511065249.81064.qmail@hotmail.com> Errors-To: droms@bucknell.edu Reply-To: pauwen@hotmail.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Georg Pauwen" To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; format=flowed; Mime-Version: 1.0 unsubscribe dhcp-v4 pauwen@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From dhcp-v4@bucknell.edu Tue May 11 09:16:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26048 for ; Tue, 11 May 1999 09:16:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA30760; Tue, 11 May 1999 09:07:37 -0400 (EDT) Date: Tue, 11 May 1999 09:07:37 -0400 (EDT) Message-Id: <199905111252.IAA00438@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCP client behavior X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 > If a DHCP client is in INIT-REBOOT state and sends DHCPREQUEST and gets > no DHCPACK or DHCPNAK. Is it correct for that client to use its previous > address if it gets no answer from an ARP request. The client is permitted to continue using the address until the lease expires, at which time it must stop using it regardless of whether or not it gets an answer to its ARP. _MelloN_ From dhcp-v4@bucknell.edu Wed May 12 09:13:45 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24575 for ; Wed, 12 May 1999 09:13:45 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA31985; Wed, 12 May 1999 09:04:33 -0400 (EDT) Date: Wed, 12 May 1999 09:04:33 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: dhcp-v4@bucknell.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: dhcp-v4@bucknell.edu (by way of Ralph Droms ) To: Multiple recipients of list Subject: RE: TCP vs UDP for Safe Failover X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 message sent to dhcp-v4@bucknell.edu by VOLZ@PROCESS.COM follows. ----------------------------------------------------------------- Regarding the TCP/UDP vs TCP only debate, I think most of the issues have been covered. But let me chime in anyway. And, I think I'm going to chime in to contracdict what I've been pushing for all along (UDP). The more I think about this, the more I feel that we DON'T need UDP. Perhaps I'm forgetting something major here and I orginally started writing this message believing we needed UDP. But as I started writing, I thought why? And started rewriting the message. What are the out-of-band POLLs used for? They really just tell us that the peer server is either back or up (not down). But, why do we need to know this "immediately"? After all, the Safe Failover protocol is designed not to require tight coupling between the servers. And, when the servers are "idle", we do want to know that the peer is alive, but if they are idle, we don't have a flow control issue and the polls will flow freely. If one server goes down and there is still data in the pipe, we'll read it eventually or our send will eventually fail. Looking at a couple of possible situations: a. Primary is sending LOTS of binding updates to secondary, but Secondary goes down. Suppose the window was closed to primary (so it can't send more). Primary will find out secondary is down because either the connection is reported down or the primary won't receive SOMETHING from the secondary within some time limit and thus take the conenction down. b. Both servers are idle and one goes down. Again, the poll timers will trigger and there won't be any response from the peer within some fixed time period. So, other server will reset connection and retry. c. Once the servers are up and running, when they exchange lots of data, is when state changes don't happen. Hence, the need to exchange POLLs to communicate state changes are primarily used when the connection isn't being used for data exchanges (hence no flow control issues in general). d. The reasons for using the POLL/POLLACK might disappear as well. One of the reasons for using that was to assure bi-directional communication with UDP (since it is possible in UDP to be able to receive packets from someone you can't send to). That is NOT possible in TCP, since the connection couldn't be established in that case. So, we might change POLLs to be more like "KEEPALIVE" messages and drop POLLACK. So, let's think this over some more and consider why we need immediate or out-of-band notification? What's the big deal if there are lots of binding updates in the "pipe"? My main reason for wanting UDP was that it was much eaiser to implement. No non-blocking socket calls. No isuses with having to deal with not being able to send. No blocking/deblocking of "records". AND, I felt that we could continue using the standard BOOTP port instead of requiring a different port, as these are unicast packets (not broadcast). So, no new sockets to deal with. And, if we ever extended the protocol to cover more than two servers, it was lower cost in not having to have a socket (connection) for each pair of servers. Again, I might be brain dead and missing something critical here. And, some folks might be unhappy as I was one of the big proponents of UDP (for the above stated reasons, not typically for protocol related issues). - Bernie Volz Process Software BTW: To address some of the issues of using TCP, like the connection collision detection (see section 6.8 in BGP RFC 1771) we can just have both servers drop the connection started by the secondary. From dhcp-v4@bucknell.edu Thu May 20 13:53:22 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01489 for ; Thu, 20 May 1999 13:53:18 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA26729; Thu, 20 May 1999 13:45:32 -0400 (EDT) Date: Thu, 20 May 1999 13:45:32 -0400 (EDT) Message-Id: <199905201719.NAA27998@prospero.dma.isg.mot.com> Errors-To: droms@bucknell.edu Reply-To: kevinb@dma.isg.mot.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kevin Benevides To: Multiple recipients of list Subject: DHCPREQUEST Question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: exmh version 1.6.7 5/3/96 I have a question with regards to a DHCPREQUEST generated during the RENEWING state. Does the server always return a DHCPACK even though it isn't extending the lease? If so, how does the client know the lease isn't being renewed? In RFC 2131, in section 4.3.2, DHCPREQUEST message generated when the client is in the RENEWING state, it states the following: A client MAY choose to renew or extend its lease prior to T1. The server may choose not to extend the lease (as a policy decision by the network administrator), but should return a DHCPACK message regardless. The state transition diagram for DHCP clients (figure 5), contradicts that statement. It shows that the client could recieve either a DHCPACK or DHCPNAK from the server, in response to a DHCPREQUEST, when the client is in the RENEWING state. I also looked at the obsoleted RFC 1541 and it also states that the client can recieve either a DHCPACK or DHCPNAK from the server when renewing or extending it's lease. Kevin Benevides Motorola From dhcp-v4@bucknell.edu Thu May 20 14:45:47 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02478 for ; Thu, 20 May 1999 14:45:46 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA27084; Thu, 20 May 1999 14:38:49 -0400 (EDT) Date: Thu, 20 May 1999 14:38:49 -0400 (EDT) Message-Id: <199905201815.OAA28955@funnel.cisco.com> Errors-To: droms@bucknell.edu Reply-To: kkinnear@cisco.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Kim Kinnear To: Multiple recipients of list Subject: Re: DHCPREQUEST Question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 At 01:48 PM 5/20/99 -0400, Kevin Benevides wrote: > >I have a question with regards to a DHCPREQUEST generated during >the RENEWING state. Does the server always return a DHCPACK >even though it isn't extending the lease? If so, how does the >client know the lease isn't being renewed? > >In RFC 2131, in section 4.3.2, DHCPREQUEST message generated when >the client is in the RENEWING state, it states the following: > > A client MAY choose to renew or extend its lease prior > to T1. The server may choose not to extend the lease > (as a policy decision by the network administrator), but > should return a DHCPACK message regardless. > >The state transition diagram for DHCP clients (figure 5), >contradicts that statement. It shows that the client could recieve >either a DHCPACK or DHCPNAK from the server, in response to a >DHCPREQUEST, when the client is in the RENEWING state. True, but I don't see that as a contradiction. If the server doesn't want to extend the lease, it should return the same expiration time it gave to the client last time in a DHCPACK. Of course, the server doesn't actually return an expiration time, but the duration of time remaining on the lease, and so it would return a shorter "remaining duration" than it returned last time, but the absolute time of expiration could be identical. Note that a client in the RENEWING state MUST have time to run on the lease. Even if the lease isn't "renewed", there is still time to run on the existing lease, or the client wouldn't be in the RENEWING state. The use of the DHCPNAK isn't to say that the server doesn't want to extend the lease, but rather for the server to tell the client that the client should stop using the IP address. That is why the state transition diagram indicates that the client MUST move into the INIT state on recepit of a DHCPNAK. Despite having sent a DHCPNAK to a client, a server cannot assume that the client has ceased to use the IP address until the client send a DHCPDISCOVER to the server (indicating that the client has entered the INIT state). Cheers -- Kim > I also >looked at the obsoleted RFC 1541 and it also states that the client >can recieve either a DHCPACK or DHCPNAK from the server when >renewing or extending it's lease. > >Kevin Benevides >Motorola > From dhcp-v4@bucknell.edu Thu May 20 14:45:57 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02491 for ; Thu, 20 May 1999 14:45:56 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA16136; Thu, 20 May 1999 14:36:53 -0400 (EDT) Date: Thu, 20 May 1999 14:36:53 -0400 (EDT) Message-Id: <199905201806.OAA19619@grosse.fugue.com> Errors-To: droms@bucknell.edu Reply-To: mellon@isc.org Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Ted Lemon To: Multiple recipients of list Subject: Re: DHCPREQUEST Question X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 My understanding of "not extend the lease" is that it will send a DHCPACK with a lease duration that's just the time left on the original lease. Whether or not the client is supposed to do anything differently if the returned interval is similar to the time remaining on its lease is another question. The ISC server doesn't actually implement this - there's no way to give out a lease but never renew it. As to the state diagram, I think a lot of client vendors have implemented to this. I am pretty sure that the Microsoft DHCP client, just to pick a completely random example, will always do the right thing if it receives a DHCPNAK while renewing. Anyway, I've seen it work for some Microsoft DHCP clients. It definitely works for the ISC DHCP client. And the ISC DHCP server will shamelessly send DHCPNAK packets to clients that are in the RENEWING state. I've never gotten a bug report indicating that this has caused a problem. I'd be interested to know the history of the paragraph you're quoting. Note that it talks about the client renewing *before* T1. Should the server's behaviour be different on a renew prior to T1 than to a renew after T1? _MelloN_ From dhcp-v4@bucknell.edu Mon May 24 11:02:01 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07293 for ; Mon, 24 May 1999 11:02:00 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA19668; Mon, 24 May 1999 10:56:24 -0400 (EDT) Date: Mon, 24 May 1999 10:56:24 -0400 (EDT) Message-Id: <000d01bea5f4$b9150b80$02015792@0080C83FB401.salford.ac.uk> Errors-To: droms@bucknell.edu Reply-To: r.j.letts@salford.ac.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Richard Letts" To: Multiple recipients of list Subject: RE: DHCP client behavior X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Behalf Of Ted Lemon > The client is permitted to continue using the address until the lease > expires, at which time it must stop using it regardless of whether or > not it gets an answer to its ARP. it might try sending packets, but in general, it won't get off the subnet. I have problems with roving Windows users, they have to manually realease and renew their IP addresses. The DHCP client seems to give up because the ARP for the router address to send a unicast DHCPrequest to the server to renew its lease on reboot. Richard Letts Desktop and Network Services Manager mail: R.J.Letts@ais.salford.ac.uk University of Salford phone: +44 161 295 5252 Great Britain fax: +44 161 295 5888 From dhcp-v4@bucknell.edu Mon May 24 14:15:22 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13124 for ; Mon, 24 May 1999 14:15:21 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA12303; Mon, 24 May 1999 14:10:08 -0400 (EDT) Date: Mon, 24 May 1999 14:10:08 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: waa@dsl.cis.upenn.edu Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "William A. Arbaugh" To: Multiple recipients of list Subject: Authentication draft- INFORM message details X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 I'm finishing up the edits and additions to the draft based on the input from the last meeting. Before I send around the entire draft for review, I want to run the details on the INFORM message for protocol 1 (shared secret MAC) by everyone. I've attached the paragraph below. Please comment directly to me or the list. The executive summary is that authentication on INFORM messages should be policy based. The server can decide to accept or reject unauthenticated INFORM messages. DHCPINFORM: Client behavior Since the client already has some configuration information, the client may also have established a shared secret value, K, with a server or servers. Therefore the client SHOULD use the authentication request as in a DHCPDISCOVER message when a shared secret value exists. The client MUST treat any received DHCPACK messages as it does DHCPOFFER messages, see Section 4.1. DHCPINFORM: Server behavior The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated DHCPINFORM messages. When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message. If the server does not have a shared secret value established with the sender of the DHCPINFORM message, then the server MUST respond with an unauthenticated DHCPACK message (see discussion below). DISCUSSION: It would be nice if the server could respond with a DHCPNACK rather than an unauthenticated DHCPACK, but my reading of 2131 indicates that this is not possible without changing the state machine. Please correct me if I am wrong. From dhcp-v4@bucknell.edu Tue May 25 12:32:29 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24222 for ; Tue, 25 May 1999 12:32:28 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA14767; Tue, 25 May 1999 12:21:13 -0400 (EDT) Date: Tue, 25 May 1999 12:21:13 -0400 (EDT) Message-Id: <374A6BBE.C8AFEA42@sharplabs.com> Errors-To: droms@bucknell.edu Reply-To: jroy@sharplabs.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: Joydeep Roy To: Multiple recipients of list X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.6 sun4u) Content-Transfer-Encoding: 7bit HELP From dhcp-v4@bucknell.edu Wed May 26 09:16:14 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23779 for ; Wed, 26 May 1999 09:16:14 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA11679; Wed, 26 May 1999 09:06:00 -0400 (EDT) Date: Wed, 26 May 1999 09:06:00 -0400 (EDT) Message-Id: Errors-To: droms@bucknell.edu Reply-To: TONY_SMALDONE@HP-USA-om12.om.hp.com Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: TONY_SMALDONE@HP-USA-om12.om.hp.com To: Multiple recipients of list Subject: HELP X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; name="Text" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit HELP From dhcp-v4@bucknell.edu Wed May 26 12:47:07 1999 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00355 for ; Wed, 26 May 1999 12:47:06 -0400 (EDT) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA01214; Wed, 26 May 1999 12:40:20 -0400 (EDT) Date: Wed, 26 May 1999 12:40:20 -0400 (EDT) Message-Id: <199905261552.QAA23113@castor.acu.ac.uk> Errors-To: droms@bucknell.edu Reply-To: a.west@acu.ac.uk Originator: dhcp-v4@bucknell.edu Sender: dhcp-v4@bucknell.edu Precedence: bulk From: "Alexandra West" To: Multiple recipients of list Subject: DHCP server problem X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion of DHCP for IPv4 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT I installed dhcpd-5.16 on a Redhat Linux 5.0 box, configured it for a few test machines and got it to work. I then transferred the configuration file to another Linux box (RedHat 5.1) where the daemon failed to start with the following error message: Can't bind to dhcp address: Address already in use exiting. I upgraded the dhcp package to version dhcp-2.0b1pl6 (it was installed from RPM not compiled from source). The README points out a particular problem with the broadcast address and suggests to route add -host 255.255.255.255 dev eth0 or route add -net 255.255.255.0 dev eth0. After having done that I tried to start dhcpd again but it is still giving me the same error message. Has anyone experienced a similar problem? If so, how did you overcome it? Help would be MUCH appreciated! Thanks Alexandra