Subject: Proposed Resolution to LLMNR Issue 87: Timeout Issues

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jul 2005 00:11:01 -0700 (PDT)

The text of LLMNR Issue 87 is enclosed below.  LLMNR Issues are tracked on
the LLMNR Issue page:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is as follows:

Change Section 2.7 to:

"2.7.  Retransmission and Jitter

   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
   when to retransmit an LLMNR query.  Rather than using a static
   timeout, an LLMNR sender SHOULD dynamically compute the value of
   LLMNR_TIMEOUT for each transmission, on a per-interface basis.

   For example, the algorithms described in RFC 2988 [RFC2988] compute
   an RTO (including exponential backoff), which is used as the value of
   LLMNR_TIMEOUT.  Smaller values MAY be used for the initial RTO
   (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
   RTO (discussed in Section 2 of [RFC2988], paragraph  2.4), and the
   maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
   Recommended values for constants (including LLMNR_TIMEOUT if it is
   set statically) are given in Section 7.  In order to take slow
   responders into account, an LLMNR sender SHOULD include responses
   received after LLMNR_TIMEOUT in the computations.

   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.
   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.  Queries with the 'C' bit set MUST be
   sent over multicast UDP and MUST NOT be retransmitted.  Responses
   to queries with the 'C' bit set are not taken into account within
   retransmission timeout computations.
   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)."

----------------------------------------------------------------------------
Issue 87: Timeout Issues
Submitter: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: May 25, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

   If TCP connection setup cannot be completed in order to send a
   unicast TCP query, this is treated as a response that no records of
   the specified type and class exist for the specified name (it is
   treated the same as a response with RCODE=0 and an empty answer
   section).

If TCP connection setup cannot be completed after how long?

[BA] If the destination is off-link, connection setup will typically
terminate immediately, due to a TTL or hopcount exceeded message.
Otherwise, I don't think a time value needs to be mandated here; this
can be left up to the implementation.

   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
   for each transmission.  For example, the algorithms described in RFC
   2988 [RFC2988] (including exponential backoff) compute an RTO, which
   is used as the value of LLMNR_TIMEOUT.  Smaller values MAY be used
   for the initial RTO (discussed in Section 2 of [RFC2988], paragraph
   2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph
   2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
   paragraph 2.5).

For this computation, does it use the first or last response received? Or
the average?

[BA] It uses each response received.

Is the RTO value computed as a single global? Per interface? Per
responding device? (Some devices are slower than others.)

[BA] It is a per-interface RTO value.

In any case, this approach has the flaw that the computed RTT estimate
converges to zero. Suppose you wait for t seconds before giving up. All
responses you get necessarily arrive in less than t seconds (ones that
arrive later are not seen). The average arrival time is therefore always
less than t, so on the next iteration you compute a smaller RTT estimate.
As RTT shrinks, more and more of the slower responses are lost, causing
RTT to be estimated only from the fast-responding set.

A specification of how to do dynamic RTT estimation in a multicast
scenario like this needs much more than just a reference to RFC 2988.

[BA] This assumes that responses are not included in the RTT and RTO
calculation if they arrive after the timeout has expired. That is not what
is intended. If the LLMNR sender receives a response after the timeout has
expired, it still includes that response in the RTT and RTO calculations.
Therefore the RTT is not estimated only from the fast-responding set and
does not converge to zero.

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