[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    LLMNR Issue 56: Miscellaneous NITs (Part 2)
From:       Ralph Droms <rdroms () cisco ! com>
Date:       2003-12-15 21:07:48
[Download RAW message or body]

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/>
[prev in list] [next in list] [prev in thread] [next in thread]