BIND 10 #1264: Design document for DHCP benchmarking utility

[BIND 10 Development]

#1264: Design document for DHCP benchmarking utility
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  johnd
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:  major  |  DHCP-20111026
                  Component:  dhcp   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DHCP
Feature Depending on Ticket:         |  Estimated Difficulty:  0
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by tomek):

 Replying to [comment:4 stephen]:
 > > In DHCPv6, All_DHCP_Relay_Agents_and_Servers is the multicast address
 to which SOLICIT requests are transmitted. Servers listen at this address
 (FF02::1:2).
 > As the tool will be distributed with BIND 10 DHCP, the code may be used
 by people not familiar with the details of DHCP for IPV6, so you may want
 to modify the description, e.g.
 > {{{
 > ...to
 > All_DHCP_Relay_Agents_and_Servers (the broadcast address FF02::1:2) via
 this
 > interface.
 > }}}
 Not true! There are no broadcast addresses in IPv6. That is multicast
 address.

 > > It should be possible to create IDs that are machine-specific (e.g.
 including a MAC address) while also including a sequence number. However,
 it now occurs to me that a fixed mapping of sequence number to transmit
 time would in any case only be sufficient for the first round of timing
 (D-O or S-A); a table will be needed to track both latencies of a 4-way
 exchange.
 > How about using even-numbered IDs for the initial packet exchange and
 (initial exchange ID + 1) as the ID for the second packet exchange?  If
 you use a four-column table (start/end time of first exchange, start/end
 time of second exchange) the ID will uniquely identify the packet exchange
 and the latency.  When you've decided on this point, a note to that effect
 should be added to the design.
 Four-column table seems reasonable. Note that first exchange (DO or SA) is
 usually quick as there is no actual lease assignment. It is expected that
 second part (RA or RR) will be much longer. Both measurements are useful.
 Also total sum of DO+RA and SA+RR should be printed as well.

 > On a related point, with the -n switch we might want to add a -o<file>
 option to output table in the form of a CSV file.  That would allow
 further analysis by external tools
 Good idea. Format should be documented somewhere. As a convenience for
 user, it can be useful to print first line commented with names of columns
 + units used (seconds, ms, bytes etc.). That's just a trivial printf() in
 the code, but it sometimes helps a lot if user doesn't know where to find
 documentation.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1264#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development