LLMNR Issue 56: Miscellaneous NITs (Part 2)

[Ralph Droms <rdroms@cisco.com>]

I'm OK with all of the responses except the changes to section 2.6
(noting that the comments about names, RRs and host configuration was
also addresses in issue 52).

I'm still not clear about the retransmission strategy described in
section 2.6.  Does this text describe it correctly?

2.6 Retransmission, collection of responses and transmission jitter

   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to
   determine when to retransmit an LLMNR query and how long to collect
   responses to an LLMNR query.

   If an LLMNR query sent over UDP is not resolved within
   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.

   Because an LLMNR sender cannot know in advance if a query sent
   using multicast will receive no response, one response, or more
   than one response, the sender 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.

   An LLMNR sender SHOULD dynamically compute the value of
   LLMNR_TIMEOUT for each transmission.  It is suggested that the
   computation of LLMNR_TIMEOUT be based on the response times for
   earlier LLMNR queries sent on the same interface.  For example, the
   algorithms described in RFC 2988 [RFC2988] (including exponential
   backoff) to 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).
   Recommended values are an initial RTO of 1 second, a minimum RTO of
   200ms, and a maximum RTO of 20 seconds.

   In order to avoid synchronization, the transmission of each LLMNR
   query and response MUST be delayed by a time randomly selected from
   the interval 0 to 200 ms.

- Ralph





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