Subject: RE: [dhcwg] dhcpv6-24: Rapid Commit

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 May 2002 11:03:41 -0500

I too would like the Rapid Commit handling improved.

In particular:

- A client should be able to send this option always if it supports it.
- Servers that don't support the Rapid Commit or have not been configured to support it should respond with Advertise messages.
- A client that receives a Reply to a Solicit w/Rapid Commit *may* use that Reply. If it doesn't, it should send a Release.
- A client must use the normal Solicit procedure and await multiple Reply messages (and Advertises). If the client receives a Reply and doesn't use the information, it must send a Release. If the client receives no Reply messages or doesn't choose to use any, it should then follow the Advertise handling as normal.

The option does have a value at least from the server / server administrator standpoint. An administrator could select not to allow this if there are multiple servers in the configuration. If there is a single server (or single set of primary/backup type servers), a server can be configured to allow Rapid Commit.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:06 AM
To: [email-masked]
Subject: [dhcwg] dhcpv6-24: Rapid Commit

This is a new addition relative to -23. I'm still trying to understand
what its actual value is. The current specification seems to have some
potential issues.

>    If the client has included a Rapid Commit option and is waiting for
>    a Reply message, the client terminates the retransmission process as
>    soon as a Reply message is received.

I'm not sure I understand the model for Rapid Commit. What happens if
two servers reply? I gather this isn't supposed to happen. Hmm.  It
seems like this is only useful if there is only one server, but in
general there is a need for multiple servers for
reliability/failover. So it seems like complexity that may not buy
much in practice. What is the deployment scenario where this is viewed
as must useful?

Also. This document doesn't provide guidance on when a client should
request this. Always? Seems like some guidance is needed, or you'll
get clients doing random things (not good for interoperability).

> 17.1.4. Receipt of Reply message

>    If the client includes a Rapid Commit option in the Solicit message,
>    it will expect a Reply message that includes a Rapid Commit option
>    in response.  If the client receives a Reply message, it processes
>    the message as described in section 18.1.6.  If the client does not
>    receive a Reply message, the client restarts the server solicitation
>    process by sending a Solicit message that does not include a Rapid
>    Commit option.

So, if the client sets the Rapid Commit, because it is in a hurry, the
process may actually take *longer* because some servers won't respond
unless the Rapid Commit is not present? This seems like a disincentive
to using the mechanism, as it might not only be quicker, it might
actually be longer, and there isn't a way for the client to know
without just trying. Right?

Also, section 18.1.6 does not  include any text about the Rapid
Commit. So, what does a client do with a response that does include
it? Doesn't include it?

Thomas

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 08:33:35 -0400

> - A client should be able to send this option always if it supports

Why even have a special option requesting it? It would be nice if the
client always did the same thing, with the servers (and how they are
configured) determining whether the Rapid Commit is enabled and to be
used. It seems odd to me that the  *client* decides when it wants the
Rapid Commit. Isn't the appropriateness of tihs determined by the
envirnment to which the client connects?
    
> - A client that receives a Reply to a Solicit w/Rapid Commit *may*
>   use that Reply. If it doesn't, it should send a Release.

Why not a MUST, not SHOULD? If the client requests a Rapid Commit, it
should be prepared to implement it fully.

> - A client must use the normal Solicit procedure and await multiple
>   Reply messages (and Advertises). If the client receives a Reply
>   and doesn't use the information, it must send a Release. If the
>   client receives no Reply messages or doesn't choose to use any, it
>   should then follow the Advertise handling as normal.

> The option does have a value at least from the server / server
> administrator standpoint. An administrator could select not to allow
> this if there are multiple servers in the configuration. If there is
> a single server (or single set of primary/backup type servers), a
> server can be configured to allow Rapid Commit.

This indicates to me this should be under server control, not client
(as in the client decides whether to request it).

Thomas