Subject: RE: [dhcwg] 'secs' field

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Feb 2006 11:46:58 -0500

Ted:

I agree that we should require clients to do this correctly. This is one
reason I try to  include the text from that draft whenever appropriate
-- while the draft has expired, it would be nice that when it is
revived, these changes can be remembered and implemented! And, best to
discuss these issues one by one as they come up in other contexts -- it
is too easy to miss something like this in a review of the draft itself.

- Bernie 

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Wednesday, February 01, 2006 11:42 AM
> To: [email-masked]
> Cc: Bernie Volz (volz); Michele Pedrolli
> Subject: Re: [dhcwg] 'secs' field
> 
> Actually, the secs field is theoretically useful in load 
> balancing, since it 
> provides you with a way to notice that a client is not 
> getting serviced by 
> the other server and step in.   So I disagree with Barr's 
> wording in the last 
> paragraph that you quoted.   It's wrong to say that clients 
> can just set this 
> field to zero all the time.   If that were not the case, why 
> did we describe 
> the Elapsed Time option in RFC3315?
> 

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

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 1 Feb 2006 10:15:03 -0800

Ted, Bernie--

You've given me far too much credit for the particular bit
of text that Bernie quoted -- I've long since forgotten
whether the source of that recommendation was Mike (Carney),
Rob (Stevens), or someone else during the review periods.

But to the point, I read it differently than you do, Ted.
Maybe the recommendation needs to be clarified.

I believe that:

(1) The client SHOULD utilize the 'secs' field if possible.

(2) If the client does not have the ability to maintain an
elapsed time value for the Discover/Offer/Request/Ack cycle,
it should set the value of the 'secs' field to zero, NOT
allowing a residual or random value to appear.  [This is a
new clarification highlighted by the current exchange opened
by Michele.]

(3) Relay agents MUST NOT alter the value of the 'secs'
field.

After that, usage starts to get squirrelly:

(a) Table 3, "Fields and Options Used by the DHCP Server,"
page 28, Section 4.3.1, "DHCPDISCOVER Message," specifies
that the 'secs' field is set to zero for the message types
OFFER, ACK, and NAK.  This seems to prohibit the example
observed and reported by Michele, expounded by Bernie.

(b) Paragraph 3, Section 3.1, "Client-Server Interaction --
Allocating a Network Address," page 16, states, "To help
ensure that any BOOTP relay agents forward the DHCPREQUEST
message to the same set of DHCP servers that received the
original DHCPDISCOVER message, the DHCPREQUEST message MUST
use the same value in the DHCP message header's 'secs' field
and be sent to the same IP broadcast address as the original
DHCPDISCOVER message," which I read as implying that the
client does not update the 'secs' field.  While I think that
implication is not what the authors intended, I feel this
sentence is confusing.  There is a second possible
interpretation that flows from this sentence, even though
paragraph 3 is clearly discussing relay agents:  that a
server might preserve the value in the 'secs' field sent by
the client.  That interpretation would match the observed
behavior reported by Michele.

To restate Ted's point, a client should not feel free to
ignore setting the 'secs' field, a point with which I both
agree, and believe was the intent of the original RFC
authors.

As I re-read RFC 2131 and the now-expired draft clarifying
the implementation issues never fully resolved, I posit two
more situations that don't seem quite right to me:

(i) Why is a DHCPINFORM message, which may be totally
independent of the Discover/Offer/Request/Ack cycle
permitted a non-zero value for 'secs?'  This might be the
case if multiple INFORMs were sent to request option values,
but it seems not to have any real purpose.

(ii) Why is a DHCPDECLINE message, which is a legitimate
client response to an ACK message, constrained to have a
zero value for 'secs?'  It seems to me that as an
[infrequently used] fifth message in the address acquisition
cycle it, too, should have a non-zero 'secs' value if the
client is capable.

At this point, I invite comments regarding all possible uses
of the 'secs' field, especially including load balancing, as
was suggested earlier in this discussion.

It seems the proper use of the 'secs' field isn't quite
settled.

--Barr

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Feb 2006 11:17:14 -0800

> DHCPDISCOVER message," which I read as implying that the

I have a feeling the author of this section intended that to
be the 'xid' field, not the 'secs' field.

I cannot imagine a reason for the 'secs' field to have any
influence on what set of servers a dhcp relay might send
queries to.

> but it seems not to have any real purpose.

I don't think that any implementation today does, or intends to,
load balance INFORMs, or otherwise make use of the 'secs' field
in INFORM processing.

The single largest scaling parameter in DHCP tends to be the
synchronization with stable storage.  LBA on INFORMs is just
not compelling, and probably harmful.

I also don't see why it shouldn't supply a value.

> cycle it, too, should have a non-zero 'secs' value if the

I believe the client's next DISCOVER after a DECLINE should
return 'secs' to zero.  It represents a new session.

The contents of the DECLINE's secs field itself is unimportant.

> was suggested earlier in this discussion.

The 'secs' field in the REQUEST is a sort of (one-shot) RTT
estimate based upon the time between DISCOVER transmission and
OFFER-reception/REQUEST-transmission.

If an environment wanted to supply lease times that were close
to this time (either due to long delays in links or very small
desired lease times), they would need to consider the 'secs'
contents at least in part when estimating an appropriate lease
time.

You certainly don't want it to take longer to renew a lease than
you've given the lease to expire.  You probably want space for
several retransmissions.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 01 Feb 2006 14:30:32 -0500

Quick bit of ancient history...

When this text was written, there were (if I recall correctly) relay agents
that would do a crude form of load balancing based on the 'secs' field.  So,
to get the DHCPREQUEST to the same server that the DHCPDISCOVER was sent to,
the 'secs' field had to be that same in both messages.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2006 14:45:45 -0700

> new clarification highlighted by the current exchange opened

It seems like if the client doesn't have this ability, it can't do the 
protocol at all anyway, so therefore there's no need to allow this exception.   
You need to be able to measure relative time in order to do exponential 
backoff in the retry algorithm.

Nevertheless, I apologize for putting words in your mouth.   :'}

> the DHCPREQUEST message MUST
> client does not update the 'secs' field. 

What this implies to me is that the DHCP client has to use the same value in 
the DHCPREQUEST secs field that it used in the DHCPDISCOVER secs field, which 
I think is a reasonable restriction.   I'm glad you pointed this out to me, 
though - in my head, I'd been thinking that the client only needed to make 
sure that the number it sent in the secs field of the DHCPREQUEST was 
_greater_than_or_equal_to the number from the DHCPDISCOVER packet.

There is an additional problem in what you've said - it's possible for a DHCP 
server to send a DHCPACK in response to a DHCPDISCOVER packet after the 
client has sent a later DHCPDISCOVER packet with a higher number in the secs 
field.   The client has no way of knowing which value for 'secs' it should 
repeat back in the DHCPREQUEST - it doesn't know the ack is for the first 
DHCPDISCOVER. 

So in practice, relay agents really need to make sure that as 'secs' 
increases, it's always the case that the set of DHCP servers to which the 
packet is relayed either stays the same or is augmented, but that no server 
is ever removed from that set as a result of secs becoming larger.   I think 
we can ignore the case where it rolls over.   DHCP servers that do load 
balancing have to only ever be increasingly permissive about responding as 
secs increase, not less permissive.

In practice, I don't know of any relay agents or servers that violate the 
constraints I just described, but if at some point we actually release the 
information you collected in that old draft, it's probably worth mentioning 
this restriction.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2006 14:50:22 -0700

> influence on what set of servers a dhcp relay might send

Microsoft used to have a relay agent that looked at secs and expanded the 
number of servers to which it forwarded as secs increased.   It's also 
possible (arguably, desirable!) to implement load balancing in a relay agent 
using the secs field as the determining factor in whether to load balance or 
relay to all servers.   I can't think of a reason why you'd ever use xid in 
this context, since the protocol pretty much requires the relay agent to 
forward the DHCPREQUEST to all the servers that got the DHCPDISCOVER - 
although I don't know of servers that particularly use the fact that the 
client chose the other server, the RFC does require that this capability be 
present.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2006 14:52:37 -0700

> contents at least in part when estimating an appropriate lease

I don't think this is practical - secs is in no way a round trip time.   There 
are a lot of factors that affect the value that a server might see in the 
secs field, and actually none of them have to do with how long the packet 
takes to get to the server.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Feb 2006 15:56:59 -0800

> backoff in the retry algorithm.

You don't need the start time...you only need to know what your
last timeout duration was, that it passed, and that your next duration
can be calculated from the last one.

A client might not be able to tell you it's been 10 seconds since it
started trying DHCP for example because it can't control wether its
source of system clock will suddenly synch due to NTP traffic on
another, addressed, interface, leaving its relative measurements in
question.

I think we all know however that the real reason a client might leave
secs zeroed is because the developer doesn't want to spend the time and
energy to fill it with a more useful value.

In which case it would be better to be zeroed than random.

---

From: "Barr Hibbs" <[email-masked]>
Date: Sat, 31 Dec 2005 16:50:35 -0800

> From: Ted Lemon
> Sent: Wednesday, February 01, 2006 13:46
>

*Snip!*

> repeat back in the DHCPREQUEST - it doesn't know
...I hadn't considered that, but it certainly does point out
an additional problem with the description of 'secs' field
usage.  The client is required to use the XID to match
responses (e.g., OFFERs) with requests (e.g., DISCOVERs) and
that should be sufficient to know to which of multiple
DISCOVER messages it is responding IF the client
implementation chooses to use different XIDs for
retransmissions (see section 4.1, "Constructing and Sending
DHCP Messages," page 24.)  As clients are stateful,
retaining the value of the 'secs' field associated with a
DISCOVER message should be simple, as long as the XIDs are
changed with each retransmission.  Otherwise, I have no idea
how to keep track of which request message is being sent a
response, so it wouldn't be possible to  send a matching
value of 'secs.'  Also, don't forget the "silent discard"
rule for OFFERs not containing the XID of the most recent
DISCOVER.

Another weird case occurred to me:  suppose a client does
not implement the exponential backoff mechanism, opting for
a much simpler method.  For instance, if no response to a
DISCOVER is received within, say 150 seconds, reset to the
INIT state.  That's clearly a protocol violation, but
beginning a new cycle at such a long interval would probably
almost never be noticed except in the very largest networks.
As a client may start with 'secs' at zero for each new [not
retransmission] address acquisition cycle.

> secs increase, not less permissive.
...This comment really confused me.  A relay agent is
obliged to preserve the value of the 'secs' field, and
require that the broadcast address used by a client is
consistent with prior usage [that particular text is not
really very precise, so some competing arguments about
behavior can certainly be raised!]  RFCs 951 and 1542
suggest that a decision about whether or not a relay agent
chooses to forward a particular request MAY use the 'secs'
field to make that determination, but RFC 1542 observes that
no actual use is known.

I don't think you can ever ensure that the set of servers to
which a relay agent forwards requests doesn't become
smaller -- factors such as network reconfiguration
(including malfunctions) or administrative controls would
always override such a design goal.

While I can imagine a relay agent selecting which requests
to actually transmit to [a set of] DHCP servers based on the
'secs' value (presumably giving preferential treatment to
those client requests indicating the length of the
bootstrapping process as seen by the client), can anyone
speak to whether or not any relay agent actually does this?
Reordering of enqueued messages based on some priority
criteria such as class of service may in fact be part of a
modern router/relay agent, but is the facility implemented
for BOOTP messages?

---

From: "Barr Hibbs" <[email-masked]>
Date: Sat, 31 Dec 2005 17:04:03 -0800

Maybe the RFC should be updated to:

o Make use of unique random values for 'XID' MANDATORY; and

o Make use of relative seconds since exiting the INIT or
INIT-REBOOT state MANDATORY.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Feb 2006 10:58:59 -0700

> In which case it would be better to be zeroed than random.

Sure, but it would be better still to just increment it every retransmission, 
so why not specify that if you're going to give the implementor a lazy way 
out?   Personally, I think that if the implementor doesn't to follow the 
spec, it's not our lookout, and giving them an easy option isn't necessary.   
If they want to put a random value in the secs field, then the market will 
take care of them.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 2 Feb 2006 10:06:47 -0800

> spec, it's not our lookout, and giving them an easy option isn't necessary.   

I agree completely.

> If they want to put a random value in the secs field, then the market will 

It's Mr. Hibbs discretion.  But if something could be said that we can
agree is liable to reduce the amount of pain that escapes software
development factories and looses itself upon our sysadmins, such words
would be noble.

I like the idea of suggesting incrementing the secs field failing all
else, but I fear it might be guilty of trying too hard to be clever.
It's adding new entropy.

We already have systems that zero secs, we already have to come up with
ways to deal with them.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Feb 2006 11:12:58 -0700

On Saturday 31 December 2005 17:50, Barr Hibbs wrote:
> I hadn't considered that, but it certainly does point out
> changed with each retransmission. 

That's a really interesting point - as far as I know, most DHCP clients use 
the same xid until they get an address, and then change.   But that's a very 
vague impression - I've never studied this in depth.   Thanks for pointing 
that out - it was not at all clear in my mind that this was how clients were 
supposed to behave.

> RFCs 951 and 1542

RFC 1542 is obsolete - you shouldn't ever mention it in any kind of reasoning 
that you do.   As you may know from a previous message, there are in fact 
relay agents that do pay attention to the secs field, or at least were as of 
NT 4.0.

> always override such a design goal.

You can't ever guarantee that some operational change won't result in some 
promise going unkept.   But you can guarantee that in the absence of an 
operational change, the promise will be kept.   It is this latter point that 
I was arguing for, not the former.   All you need to do in the absence of an 
operational change to keep the restriction I suggested is to implement things 
so that the set of servers to which you forward at time T is always identical 
to or a subset of the set of servers to which you forward at time T+k, for 
all positive values of k up to the wraparound point.   This is totally 
trivial, and is in fact what Microsoft's implementation did.

> modern router/relay agent, but is the facility implemented

Who said anything about reordering?

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 3 Feb 2006 09:27:09 -0800

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, February 02, 2006 10:13
>
> > RFCs 951 and 1542 suggest that a decision about whether
or not a
> > relay agent chooses to forward a particular request MAY
use the
> > 'secs' field to make that determination, but RFC 1542
observes
> > that no actual use is known.
>
> RFC 1542 is obsolete - you shouldn't ever mention
> it in any kind of reasoning that you do.
>
...that's not quite right: 1541 is obsolete, but 1542 is a
Draft Standard

> As you may know from a previous message, there are in fact
> relay agents that do pay attention to the secs field, or
> at least were as of NT 4.0.
>
...what I didn't say very well is that I didn't understand
how a relay agent can use 'secs' to any better advantage
than 'hops' for making the determination whether or not to
forward a received request packet, which seemed to my
reading to be [one of] the purposes of the field.  With
additional review of the Windows 2000 Server options, I saw
how Microsoft makes use of 'secs' to moderate the forwarding
of request packets (not that their explanation is terribly
lucent, but what the heck, nobody's perfect.)

> Who said anything about reordering?
...this is at the heart of my confusion:  I read all
descriptions of the use of the 'secs' field by relay agents
without understanding the intended purpose, so I dropped
back to my prior experience with record communications
(anybody else remember message switching?), where the
outbound communications links were often slow enough that
queues of messages waiting to be delivered to a destination
would form.  In an environment where heavy queueing is
possible, a policy to expedite delivery of the oldest
packets implies that strict FIFO queueing is not required --
in fact, as UDP does not guarantee the order of packet
delivery, it wasn't such a weird stretch.

In fact, I still assert that the RFC text is not at all
clear as to the intention nor usage of the 'secs' field.
So, to my mind, each outbound link from a relay agent is
queue-driven, and when a new packet arrives, it *could* be
placed on the head of the queue rather than the tale based
entirely on the 'secs' field, thereby implementing a policy
of attempting to minimize the overall delay time acquiring
an IP address.

Given that remote links to servers are much more likely to
be considerably slower than the [multiple] links from
clients, I suspect that even modern, high-performance
routers may experience packet queueing, hence my
unsubstantiated conclusion that packet reordering could be
inferred from the sketchy description of the 'secs' field.

Of course, if I'd remembered that section in the DHCP
handbook which I reviewed oh, so long ago, we wouldn't have
had this curious trip down memory lane, to the days of 12.5
bps telegraph lines and message switching.

--Barr

---

From: Robert Elz <[email-masked]>
Date: Sat, 04 Feb 2006 14:09:22 +0700

Date:        Fri, 3 Feb 2006 09:27:09 -0800
    From:        "Barr Hibbs" <[email-masked]>
    Message-ID:  <[email-masked]>

  | ...that's not quite right: 1541 is obsolete, but 1542 is a
  | Draft Standard

I suspect that what Ted may have meant, is that an RFC published in 1993
which is attempting to say what has been observed in the world, isn't
likely to be very useful for any current practical purpose.

  | In fact, I still assert that the RFC text is not at all
  | clear as to the intention nor usage of the 'secs' field.

My impression has always been that this was, to some degree, deliberate.
That is, relay agents, servers, etc, can use it for any purpose that they
like - with the most likely (I assume) type of purpose being to try a
bit harder to satisfy a request that seems to be for a node that has
been looking for its address for a long time.

What that means in practice will depend upon the implementations, it might
mean answering a request the server would normally have left for someone
else to handle, or it might mean forwarding a request from a relay agent
further away from the client than the relay agent normally would, or ,...

It can't allow anything that ought to be prohibited, as there's nothing
stopping a client simply sticking 65535 in the field for its first
request (or perhaps, to be a little less obvious, 77 or something big
enough, but not absurd).

kre

---

From: "Barr Hibbs" <[email-masked]>
Date: Sat, 4 Feb 2006 11:11:04 -0800

> From: Robert Elz
> Sent: Friday, February 03, 2006 23:09
>

*Snip!*

> request (or perhaps, to be a little less obvious,
...I think your comments go right to the heart of the
question:  we should resist trying to overspecify the
behavior of servers and relay agents, instead clarifying a
simple behavior on the part of a client that will enable
implementors of servers and relay agents to implement
behavior or a policy mechanism as they see fit.

I'm going to update the implementation issues draft, and
will supply slightly clarified wording for that purpose.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Feb 2006 10:17:41 -0700

> likely to be very useful for any current practical purpose.

It's kind of you  to offer such an optimistic interpretation, but in fact 
what's really going on is that I have this  idea firmly in mind that the 
now-obsolete DHCP and DHCP/BootP Vendor extensions drafts were numbered 
sequentially like the current ones, so I think that RFC2131 == RFC1541 and 
RFC2132 == RFC1542, but in fact RFC1542 is only tangentially related to 
RFC1533.   So I thought Barr was referring to RFC1533, and that's why I said 
it was obsolete.