Subject: [dhcwg] dhcpv6-24: Rapid Commit

From: Thomas Narten <[email-masked]>
Date: Wed, 08 May 2002 11:05:33 -0400

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: Ted Lemon <[email-masked]>
Date: Wed, 8 May 2002 11:09:06 -0500

The rationale for rapid commit is that there are devices that need to 
operate over a limited-bandwidth link, where the cost of the additional 
message exchange is significant.   For example, a cell phone.   Also, rapid 
commit introduces less latency to the address configuration process, which 
can be very significant in some cases.

With respect to the dual server model, the idea is that both servers do 
rapid commit, but the client only binds one of the server's addresses, and 
it simply drops the other server's addresses.   When it goes to renew, it 
only talks to the server it bound to, so the other leases expire, and the 
addresses burned by rapid commit are reclaimed.   This is considered okay 
because we have addresses to burn, and we consider the rapid commit to be 
more important than the burned addresses, which are reclaimed fairly 
quickly anyway.

I think that you are right to object to the specific implementation we've 
described.   It would be better to insist that the client be prepared to do 
the four-way handshake if it doesn't get a Reply with the rapid commit 
option - that is, a server can ignore the rapid commit option and send a 
Reply without it, and the client can wait if it wants to see if some other 
server replies with Rapid commit, or it can immediately proceed with the 
four-way handshake.   I don't see any reason to require that the client 
restart the whole process without rapid commit if it doesn't receive a 
reply - I would expect it to be the server provider's responsibility to 
make sure that all DHCP servers that serve a link where rapid commit is 
desired are configured to actually support rapid commit.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 08 May 2002 19:44:30 -0400

At 11:05 AM 5/8/2002 -0400, Thomas Narten wrote:
>what its actual value is.

The value is to allow a two message exchange for address assignment in
certain situations.

>  The current specification seems to have some
>potential issues.
>

One scenario in which this is useful is when a service provider implements
a DHCP server in its edge router.  There is reduced need for server
redundancy - if the router isn't running, the subscriber can't use the
network, anyway.  The subscriber CPE talks to one server, the one in the
router.

>get clients doing random things (not good for interoperability).

Guidance is probably appropriate...

>without just trying. Right?

The authors did discuss allowing a server respond with an Advertise
to a Solicit/Rapid Commit.  In that way, the client could proceed
with a four message exchange with no penalty.

In practice, although we haven't captured this well in the doc, I
expect that DHCP clients in general purpose computers will always
use the four message exchange.  Specialized devices - for example,
CPEs and phones - will use Rapid Commit in scenarios where the
DHCP service is deployed to take advantage of Rapid Commit.

>Commit. So, what does a client do with a response that does include

Clarification required...

---

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

> message exchange is significant.   For example, a cell phone.

Hmm. Note  that the bandwidth cost is *NOT* determined by the client
type (e.g., cell phone), but the kind of links that are employed. It
is misleading and potentially inaccurate to say all cell phones will
be on bandwidth limited networks.

Also, here I assume you mean bandwidth, not latency. In order to
complete the analysis, one must also take into account what happens if
the Rapid Commit isn't implemented (more messages?) or if multiple
Reply's are received (and then followup releases are needed...)

> Also, rapid commit introduces less latency to the address
> configuration process, which can be very significant in some cases.

This isn't clear to me based on the text in the  ID.  If Rapid Commit
isn't supported, there are more messages exchanged. This means more
wasted bandwidth.

But if the semantics are that servers can respond with either Reply or
Advertise, I think the above concerns can be better dealt with.

> more important than the burned addresses, which are reclaimed fairly 

We may have addresses to burn, but it now also means that a site
doesn't really know which addresses are being used. I.e., If there are
two servers, up to 1/2 of the assigned addresses may not actually be
in use. Will sys admins like this model? I'm not sure.

> desired are configured to actually support rapid commit.

Make sense to me.

Thomas