Subject: Revised Proposed Resolution to LLMNR Issue 46: Retransmission Behavior

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Sep 2003 14:01:29 -0700 (PDT)

Below find the text of Issue 46.  The proposed fix is as follows:

Change Section 2.6 from:

"2.6. Retransmissions

In order to avoid synchronization, LLMNR queries and responses are
delayed by a time uniformly distributed between 0 and 200 ms.

If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
the query in order to assure that it was received by a host capable of
responding to it. Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received for a query,
on a per-interface basis. The algorithms described in [RFC2988] are
suggested, with a
minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD
NOT be attempted more than 3 times. Where LLMNR queries are sent using
TCP, retransmission is handled by the transport layer."

To:

"2.6. Retransmissions

In order to avoid synchronization, LLMNR queries and responses are
delayed by a time randomly selected from the interval 0 to 200 ms.

If an LLMNR query sent over UDP is not resolved within the timeout
interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the
query in order to assure that it was received by a host capable of
responding to it. Retransmission of UDP queries SHOULD NOT be attempted
more than 3 times. Where LLMNR queries are sent using TCP, retransmission
is handled by the transport layer.

Since a multicast query sender cannot know
beforehand whether it will receive no response, one response, or
more than one response, it SHOULD wait for LLMNR_TIMEOUT
in order to collect all possible responses, rather than considering the
multicast query answered after the first response is received. A unicast
query sender considers the query answered after the first response is
received,
so that it only waits for LLMNR_TIMEOUT if no response has been received.

LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received for a query,
on a per-interface basis. The algorithms described in [RFC2988] are
suggested (including exponential backoff). Smaller values of RTOinitial,
RTOmin and RTOmax MAY be used. Recommended values are RTOinitial=1 second,
RTOmin=200ms, RTOmax=20 seconds. "

-------------------------------------------------------------------------
Issue 46: Retransmission behavior
Submitter name: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: August 24, 2003
Reference:
Document: LLMNR-22
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

>For each UNIQUE resource record in a given interface's configuration,
>the host MUST verify resource record uniqueness on that interface. To
>accomplish this, the host MUST send an LLMNR query for each UNIQUE
>resource record.

How many LLMNR queries? What interval?

How long after the query (or queries) may it start issuing responses for
that name?

[BA] UNIQUEness verification is handled similarly to any other query, as
specified in Section 2.6.

What about tie-breaking in the event of simultaneous startup (e.g. when
power is restored after an outage)?

[BA] The draft does not specify what is done in the event of a name
conflict. In general, automatic name change may be neither possible nor
desirable.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>