[ipxe-devel] DHCP timeouts
Alex Williamson
alex.williamson at redhat.com
Wed Jun 5 19:26:58 UTC 2013
Hi,
Looking through the code and the RFCs and specs, I'm having trouble
understanding why iPXE does what it does for DHCP/PXE timeouts. As I
understand it, the code will currently re-transmit discovery packets
with delays of 1,2,4,8 seconds. This gives a timeout after a total of
15 seconds. However RFC2131 indicates the initial retry should be after
4 seconds with exponential backoff up to a maximum of 64 seconds. Thus
we should use retry delays of 4,8,16,32,64 seconds. It's a little
ambiguous whether we send that last packet, so this could also be
interpreted as 4,8,16,32 for a total of 60 seconds. This is actually
how the PXE specification defines it.
So, the first question is why do we take such an abbreviated approach?
Is there a spec that supports it?
Re-transmission of the request response is a little more difficult.
RFC2131 suggests using the same backoff algorithm as above, with a 60s
total timeout. The PXE spec indicates re-transmission timeouts of
1,2,3,4 seconds. iPXE retries with delays of 0.25,0.5,1,2,4,8 seconds.
Next, when sending option 60, the PXE spec defines that the client
should wait through the 4 and 8 second timeouts for a response that
includes the PXEClient tag. iPXE waits for 2 seconds total to have
elapsed. Why? Are we just trying to reduce that 12 second delay in a
non-PXE environment?
If there's agreement that at least the discovery phase should be
something closer to the spec defined intervals, I can post a patch.
Thanks,
Alex
More information about the ipxe-devel
mailing list