Subject: Proposed Resolution to Issue 46: Retransmission Behavior

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Sep 2003 21:55:21 -0700 (PDT)

The text of Issue 46 is enclosed below.  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, on a per-query
basis. The algorithms described in [RFC2988] (including exponential
backoff)
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 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."

------------------------------------------------------------------------

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/>

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Sep 2003 13:04:40 +0700

Date:        Thu, 4 Sep 2003 21:55:21 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | The text of Issue 46 is enclosed below.  The proposed fix is as follows:

  | To:
  | 
  | 
  | "2.6. Retransmissions
  | 
  | In order to avoid synchronization, LLMNR queries and responses are
  | delayed by a time uniformly distributed between 0 and 200 ms.

I know that sentence isn't what is being proposed to be changed, but
while this section is being worked on, I would suggest that it should
be - not any kind of substantive change, just wording.

That is, I don't think it makes any sense to have *a* time that is
uniformly distributed, I don't think that makes either grammatical
or mathematical sense.

What I think is the intent is to have the delays selected by various
queries and responses form a uniform distribution, but that's between
difficult and impossible to specify or enforce.   All that's needed is
to require a random selection of the delay value in the 0..200 ms
interval, and then we can rely upon the properties of random numbers
to assume that the distribution of delays will turn out to be uniform.

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

kre