Subject: Rules for message transmission and retransmission

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Jul 2001 07:00:06 -0400

Ted suggests that the spec define a single set of rules for message 
transmission and retransmission, and then alter the definition of client 
behavior for each message to refer to that definition.  I've included the 
new text for transmission and retransmission below, along with an example 
of how the text for the Solicit message would refer to that new text.  Note 
that the Solicit message also includes new text describing the client 
behvaior in the case that it receives no responses to its Solicit message.

Please reply to the mailing list with your comments about this new 
text.  I'm going to cut off discussion of this issue Thursday (7/19) 
afternoon at 2PM EDT.  Jim and I plan to publish the -20 rev of the draft 
before the London IETF deadline, and we'll need time to make the final 
edits to the draft.

- Ralph

12-1/2. Retransmission of Messages. (To be inserted between existing
                                      sections 12 and 13)

    The UDP protocol does not provide a reliable mechanism for datagram
    delivery.  In some cases it is therefore necessary to retransmit
    packets.  An initiator of a protocol exchange must therefore wait
    for some period of time after transmitting a message and, if no
    reply is received, retransmit that message.

    Rather than specify retransmission behaviour for each individual
    case where retransmission may be called for, we specify it here.
    Please note that this retransmission algorithm MUST NOT be applied
    except in cases where it is specifically called for.   It is not
    the case that all packets are retransmitted.

    Retransmission behaviour is controlled by between two and four
    variables.  All retransmission algorithms have an initial
    retransmission time (IRT).  In some cases a maximum retry count
    (MRC), maximum retry time (MRT), and/or maximum retry duration
    (MRD), may also be specified.  These three letter acronyms will be
    used later in this document when we refer to this section.

    When an initial transmission occurs, the transmitting agent sets
    the retransmission timout (RT) value to IRT plus the product of a
    random quantity between -1/10 and 1/10 multiplied by IRT:

	RT = IRT + (rnd (-0.1, 0.1) * IRT).

    On each subsequent transmission, the retransmission timeout is set
    to the previous retransmission timeout multiplied by two plus the
    a randomly chosen number between -1/10 and 1/10 multiplied by
    of the previous retransmission timeout:

	RT' = (RT * 2) + (rnd (-0.1, 0.1) * RT)

    If MRT is defined and the new retransmission timeout is greater
    than MRT, it is set to MRT multiplied by a randomly chosen number
    between 9/10 and 1 1/10:

	if (RT' > MRT)
		RT' = MRT * rnd (0.9, 1.1)

    Unless otherwise specified, when a response is received to a
    transmission, the retransmission process MUST be immediately
    terminated.  If MRC is defined and the packet has been transmitted
    MRC times, the retransmission process MUST be terminated, except
    that if MRC is -1, the retransmission process MUST continue until a
    response is received.  If MRD is defined and that many seconds have
    elapsed since the first message was transmitted, the retransmission
    process MUST also terminate.

    The algorithm used to choose a random number does not need to be
    cryptographically sound, but it SHOULD produce a different sequence
    of numbers on each invocation of the DHCP client.   The element of
    randomness prevents similar client implementations from getting
    into lock-step.

    When computing timeouts, the computation MUST be done in such a way
    that it is accurate to at least the nearest millisecond, and when
    processing timeouts, at least the same degree of accuracy SHOULD be
    used.  In any case, timeout processing MUST be accurate to at least
    500 milliseconds.

=====
(Replacement text for existing section 13.3.2)

13.3.2. Time out and retransmission of Solicit Messages

    The client's first Solicit message on the interface MUST be delayed
    by a random amount of time between the interval of MIN_SOL_DELAY and
    MAX_SOL_DELAY. This random delay desynchronizes clients which start
    at the same time (e.g., after a power outage).

    The client then uses the retransmission algorithm described in 12a,
    using ADV_MSG_TIMEOUT for IRT, ADV_MSG_MAX for MRT, and
    SOL_MAX_ATTEMPTS for MRC.  Receipt of an Advertise message prior to
    ADV_MSG_TIMEOUT does not terminate the retransmission process - the
    client will continue to listen for advertise messages until
    ADV_SEL_TIMEOUT has expired.   A retransmission MUST NOT be
    scheduled for the same time that ADV_SEL_TIMEOUT will expire.

    After SOL_MAX_ATTEMPTS attempts have been made, the client MUST
    stop trying to configure the interface using DHCP.  When the client
    has stopped trying to configure the interface, it SHOULD NOT try
    again to configure the interface unless some external event occurs.
    Examples of external events include but are not limited to
    user-initiated events, system reboots, and the client being
    connected to a new network link.  Unless there is some reason to do
    otherwise, DHCP clients SHOULD be configured with SOL_MAX_ATTEMPTS
    at -1 by default, so that the client never stops attempting to
    configure the interface.

[Note: I can see why it must be necessary for the client to give up in
some extreme cases, but from an operational perspective on a normal
network, this would be a disaster, so I've tried to wordsmith the
above language to make it glaringly obvious that it is the exception
rather than the rule that clients should stop trying to configure the
interface.   Also, the language that allowed the client to continue
retransmitting after SOL_MAX_ATTEMPTS expired doesn't make sense - if
you want that behaviour, why not just set SOL_MAX_ATTEMPTS to -1?]

    If the client detects that it has moved to a new link (see section
    14.3.2 for examples of when this can occur) the client MUST restart
    the server solicitation process.

    Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
    ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.