Re: [dhcwg] dhcpv6-24: Rapid Commit

[Thomas Narten <[e-mail]>]

> 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.

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.

> 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.

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.

> 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.

Make sense to me.

Thomas

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