Subject: [dhcwg] DHCP Process Time

From: Hans Christian Silaban <[email-masked]>
Date: Wed, 28 Sep 2016 15:18:57 +0700

Hi there,
I'm doing a research about DHCP option. I wan't to analyze the DHCP process
time before and after implement the option. Is there any standard that for
the DHCP process time? I mean from the DHCP DISCOVER until DHCP ACK. Thank
you.

Yours Faithfully,

*Yohanes Bosco Hans Christian Sihombing*
[email-masked]
<[email-masked]>
<https://instagram.com/ybhanscs>  <https://www.linkedin.com/in/ybhanscs>
<https://github.com/bschans>

---

From: Karl Auer <[email-masked]>
Date: Wed, 28 Sep 2016 18:30:00 +1000

On Wed, 2016-09-28 at 15:18 +0700, Hans Christian Silaban wrote:
> I'm doing a research about DHCP option. I wan't to analyze the DHCP
> process time before and after implement the option. Is there any
> standard that for the DHCP process time? I mean from the DHCP
> DISCOVER until DHCP ACK.

Not quite sure what you mean, but there would seem to be four obvious
methods to look at the protocol and compare before and after:

1: Turn on verbose logging on whatever server you are using and inspect
the logs

2: Run Wireshark on the client and inspect the traffic in real time

3: Capture the traffic on the client or the server using eg tcpdump,
then inspect it later in Wireshark

4: Tap a suitable switch port and capture or inspect traffic to/from
the server.

Wireshark will be able to decode your DHCP options for you. It has an
extensive set of decodes for standard and well-known options. If you
are using something special, you may need to get comfy with hex or
write a decode for your special option.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

---

From: [email-masked]
Date: Wed, 28 Sep 2016 10:29:02 +0200 (CEST)

> the DHCP process time? I mean from the DHCP DISCOVER until DHCP ACK. Thank

As far as I know there is no standard for DHCP process time. Also, I'm
not sure how relevant it is: I would expect the additional processing
time for one extra DHCP option to be barely measurable. The *server*
is probably going to spend more time doing disk writes and logging.

Steinar Haug, AS 2116

---

From: Simon Hobson <[email-masked]>
Date: Wed, 28 Sep 2016 12:21:14 +0100

> 2: Run Wireshark on the client and inspect the traffic in real time
...

I can't help thinking that the overhead of handling just one extra option would be completely lost in the natural variation in timing. I'd have thought that just the variation in disk access times (for updating the leases file) could run into 10's of milliseconds - vs (I'd have thought) some small fraction of a millisecond for processing the extra option.

---

From: Karl Auer <[email-masked]>
Date: Wed, 28 Sep 2016 21:35:13 +1000

On Wed, 2016-09-28 at 12:21 +0100, Simon Hobson wrote:
> > Not quite sure what you mean, but there would seem to be four
> > obvious methods to look at the protocol and compare before and
> > after:
> 
> I can't help thinking that the overhead of handling just one extra
> option would be completely lost in the natural variation in timing. 

Yes - but I just didn't really know the OP meant. I think your
interpretation - that the OP wanted to compare the processing time with
and without a particular option - is probably correct.

As is your thought that the processing cost for one option is probably
negligible compared to other overheads. On the other hand, we don't
know what server is being used or what the special option is. Maybe it
makes more sense than we think. Maybe the OP is just being diligent and
making no assumptions about the effects of adding this option.

We run the Nominum DCS server, which has hooks for user-supplied code,
and it's certainly possible for that to chew a lot of CPU if we get it
wrong.

Regards, K.