Subject: LLMNR Issue 100: Retransmission Behavior

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Aug 2005 22:00:24 -0700 (PDT)

LLMNR Issue 100 (Retransmission Behavior) was received in IETF last call.  
The text of the issue is enclosed below.  The proposed resolution is as 
follows:

Change Section 2.7 to the following:

"2.7. Retransmission and Jitter

An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
when to retransmit an LLMNR query. An LLMNR sender SHOULD either
estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
high initial timeout. Suggested constants are described in Section 7.

If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it,
while increasing the value of LLMNR_TIMEOUT exponentially.
An LLMNR query SHOULD NOT be sent more than three times.

Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer. Queries with the 'C' bit set MUST be
sent using multicast UDP and MUST NOT be retransmitted.

An LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
has been received, or if it is necessary to collect all potential
responses, such as if a uniqueness verification query is being made.
Otherwise an LLMNR sender SHOULD consider a multicast query answered
after the first response is received, if that response has the 'C'
bit clear.

However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
responses. When multiple valid answers are received, they may first
be concatenated, and then treated in the same manner that multiple
RRs received from the same DNS server would. 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.

Since it is possible for a response with the 'C' bit clear to be
followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of
conflict detection and LLMNR_TIMEOUT estimation, even after it has
considered a query answered.

In order to avoid synchronization, the transmission of each LLMNR
query and response SHOULD delayed by a time randomly selected from
the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responders responding with names which they have previously
determined to be UNIQUE (see Section 4 for details)."

Change Section 7 to the following:

"7. Constants

The following timing constants are used in this protocol; they are
not intended to be user configurable.

JITTER_INTERVAL   100 ms
LLMNR_TIMEOUT     1 second (if set to the same value on all interfaces)
                  100 ms (IEEE 802 media, including IEEE 802.11)"

--------------------------------------------------------------------------
Issue 100: Retransmission Behavior
Submitter: Yi Zhao
Submitter email address: [email-masked]
Date first submitted: August 18, 2005
Reference:
Document: LLMNR-42
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue: 

Section 2.7 describes two alternatives, a static timeout
(presumably the same for all media) or dynamic timeout computation.

A universal static timeout on all interfaces will not work well
because a one second timeout value is too high for Ethernet,
and too low for other media such as GPRS.

However, the techniques described in RFC 2988 also will not
work well for LLMNR, because LLMNR_TIMEOUT would need to be
estimated separately for each responder.

My suggestion is to estimate the round-trip times for each
interface or set a reasonably high initial time-out, while
backing off timeouts exponentially. This is similar to the
recommendation in RFC 1536 for DNS resolvers.

For example, on Ethernet, the initial timeout value
might be 100 ms, followed by 200 ms, and 400ms.

BTW, I think Section 2.7 means to say that an LLMNR query
should not be sent more than 3 times, not that it should
not be retransmitted more than 3 times (which would allow
a query to be sent 4 times). Even only IEEE 802.11 (which
allows frame error rates of up to 10 percent for multicast
frames sent from AP to STA), sending the query 3 times should
be enough. 

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