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      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => johnd


Comment:

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

 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

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