Subject: RE: Reconfigure-init message in DHCPv6

From: Ralph Droms <[email-masked]>
Date: Thu, 31 May 2001 06:21:44 -0400

I agree with Bernie that the mechanisms for sending Reconfigure-init to 
multiple clients is an implementation issue and shouldn't be specified in 
the spec.

The next draft will use a slightly different strategy for the transaction 
ID.  As suggested by Thomas Narten, the transaction ID in the client's 
Request message can be independent of the transaction ID in the 
Reconfigure-init message.

However, we still have an issue with the transaction ID in retransmitted 
Reconfigure-init messages.  If the server uses the same transaction ID in a 
retransmitted message, how does the client differentiate retransmission 
from duplicate messages?

- Ralph

At 04:40 AM 5/31/2001 -0500, Bernie Volz (EUD) wrote:

>I would think that how a server deals with this is an implementation issue 
>and should not be covered by the protocol. The protocol can accommodate 
>either mode - it really is up to the server to deal with this. I would 
>suspect that (1) is more likely. Perhaps the most typically implementation 
>may be to send requests to <N> clients and then wait for the clients to 
>respond (or timeout) and as they do, send additional requests. This avoids 
>flooding the network with packets and also staggers client responses some. 
>Approach (2) is likely not very good as it would, as you point out, take a 
>very long time if there are a lot of clients.
>
>I don't believe there is any need for the transaction id to be the same 
>for all clients (retransmitted requests to a particular client should use 
>the same id). Note though that there is little reason why the server would 
>necessarily need a new transaction id for each client - it could use the 
>same for all clients if it wanted to. Again, I think this is an 
>implementation issue.
>
>- Bernie Volz
>
>-----Original Message-----
>From: [email-masked] 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, May 31, 2001 2:12 AM
>To: DHCPv6 discussion list
>Cc: [email-masked]; [email-masked]
>Subject: RE: Reconfigure-init message in DHCPv6
>
>
> >>Per discussions during a design team meeting and at the March IETF, we
> >>hope to punt on the multicast reconfigure-init support for now.
> >
> >Yes, Reconfigure-init will *not* have multicast as an option in the next
> >DHCP spec draft.
> >
> >
> >- Ralph
>
>I have doubt on how does a server send RECONFIG message If it tries to
>reconfigure a network. Does it send
>      1) RECONFIG to all the clients once, and waits for REQUEST from
>clients.
>      (Or)
>      2)  it sends RECONFIG messages one by one to all clients and ensures
>that all clients gets reconfigured. In that case the server should wait for
>RECCREP_MSG_TIMEOUT ( default 2000 ms) for REC_MSG_ATTEMPTS ( default 10)
>times, which means it has to wait for 20 seconds for a node, and it may
>take too long to configure whole network.
>
>Is the transaction id is going to be same for all messages or different in
>both the cases.....
>
>suresh.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 31 May 2001 10:08:28 -0400

Oops, sorry.  I responded without thinking all the way through Thomas' 
suggested mechanism for Reconfigure-init - in fact, I think it actually 
does solve the transaction ID problem...

As I understand it, the Reconfigure-init message acts as a trigger that 
signals the client to complete a successful Request/Reply message 
exchange.  Once the client has received a Recongfigure-init, the client 
proceeds with the Request/Reply message exchange (retransmitting the 
Request if necessary); the client ignores any additional Reconfigure-init 
messages (regardless of the transaction ID in the Reconfigure-init message) 
until the Request/Reply exchange is complete.  Subsequent Reconfigure-init 
messages (again independent of the transaction ID) cause the client to 
initiate a new Request/Reply exchange.

OK, so how does this mechanism work in the face of duplicated or 
retransmitted Reconfigure-init messages?  Duplicate messages will be 
ignored because the client will begin the Request/Reply exchange after the 
receipt of the first Reconfigure-init.  Retransmitted messages will either 
trigger the Request/Reply exchange (if the first Reconfigure-init was not 
received by the client) or will be ignored.  The server can discontinue 
retransmission of Reconfigure-init messages to the client once the server 
receives the client's Request.

It might be possible for a duplicate or retransmitted Reconfigure-init to 
be sufficiently delayed (and delivered out of order) to arrive at the 
client after the Request/Reply exchange (initiated by the original 
Reconfigure-init) has been completed.  In this case, the client would 
initiate a redundant Request/Reply exchange.  I think (although I could be 
convinced otherwise) that the likelihood of delayed and out of order 
delivery is small enough to be ignored.  Also, the consequence of the 
redundant exchange is inefficiency rather than incorrect operation.

I'll write up this new mechanism in the next draft of the spec.

- Ralph

At 06:21 AM 5/31/2001 -0400, Ralph Droms wrote:
>Reconfigure-init messages.  If the server uses the same transaction ID in 
>a retransmitted message, how does the client differentiate retransmission 
>from duplicate messages?
>
>- Ralph
>
>>I would think that how a server deals with this is an implementation 
>>issue and should not be covered by the protocol. The protocol can 
>>accommodate either mode - it really is up to the server to deal with 
>>this. I would suspect that (1) is more likely. Perhaps the most typically 
>>implementation may be to send requests to <N> clients and then wait for 
>>the clients to respond (or timeout) and as they do, send additional 
>>requests. This avoids flooding the network with packets and also staggers 
>>client responses some. Approach (2) is likely not very good as it would, 
>>as you point out, take a very long time if there are a lot of clients.
>>
>>the same id). Note though that there is little reason why the server 
>>would necessarily need a new transaction id for each client - it could 
>>use the same for all clients if it wanted to. Again, I think this is an 
>>implementation issue.
>>
>>- Bernie Volz
>>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 31 May 2001 19:21:19 -0400

> retransmitted message, how does the client differentiate retransmission 

Does it need to? 

If the client is in the process of contacting the server when the
retrasmission comes in, it knows it's a retransmission (i.e., that is
presumably why it is trying to contact the server) and it just ignores
the retransmission.

The other case is where the client responds to the server's
Reconfigure-Init does a transaction (that completes) and *then* a
retransmission arrives essentially saying "contact me again". 

I few observations:

1) this is somewhat pathological situation. Either the server is
   broken (it's retransmitting even after its original request has
   been "acknowledged" via the client contacting it and getting the
   new options) or the network is delaying some packets for a real
   long time.

2) if the client contacts the server again, nothing breaks, though
   there is a performance penalty.  The client just gets the same info
   over again.

3) if this was a real concern, the client can retain state (even after
   contacting the server) that keeps track of the last transaction ID,
   in which case it would recognize the retransmission and ignore
   it. 

Or do I misunderstand the concern?
   
Thomas

---

From: Ralph Droms <[email-masked]>
Date: Thu, 31 May 2001 21:28:18 -0400

Thomas - you're right, the client doesn't need to consider the transaction 
ID.  I think I got the argument right in my followup note (that crossed in 
flight with your e-mail).

Please see if you agree with the DISCUSSION section in the text snippet I 
posted.

- Ralph