[dhcwg] dhcpv6-24: Rapid Commit

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:10 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11330 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:10:01 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04516 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:10:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03879; Wed, 8 May 2002 11:05:11 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03850 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:05:10 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10922 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:05:00 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com []) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F5964126130 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:05:09 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F59Q221082 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:05:09 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F5XQ19207 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:05:33 -0400
Message-Id: <200205081505.g48F5XQ19207@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:05:33 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: Rapid Commit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

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?


dhcwg mailing list