Subject: [NSIS] RE: Retransmitted Queries

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Feb 2007 10:17:48 -0000

hi roland,

sorry for the delayed reply. 

my instinct here is that there is a fundamental (functional)
benefit in  having retransmitted queries use different cookies,
and a possible performance benefit in not - but that actually
i believe that performance benefit does not arise in practice.

the functional benefit is that it is good to know if two 
messages are the same or not. one is for reply correlation for
rtt measurement (as you mention). another is for network 
debugging - if you see two identical messages, you *know* that
they have been replicated in the network or some buggy piece
of software, rather than the possibility that they are 
retransmissions. (my thinking on this is inspired by a certain
amount of time worrying over TCP traces and suchlike, where
it is a major frustration not knowing which instance of a piece
of data is being acknowledged).

if you allowed identical queries, there *might* be some advantages,
but see below in-line ...

given this tradeoff, i'd rather leave things as they are.

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 24 November 2006 16:21
> To: Hancock, Robert; [email-masked]
> Subject: Retransmitted Queries
> 
> Hi Robert and all,
> 
> In section 5.3.3. there is the statement:
> 
>   Retransmitted Queries MUST use different Query-Cookie values.
> 
> Is there any rationale for this (yes, I read sec. 8.5)?
> I cannot see any real benefit in doing
> so (except for the case that you want to measure round-trip times).
> Replay attacks seem to cause no harm, because they do not
> cause additional state to be installed. In the current situation,
> we have often seen the case where retransmissions and responses
> are crossing each other (or two queries are transmitted back-to-back)
> and the responder has to send one response for each query until the
> backoff is large enough to allow a query cookie match for the latest
> query/response pair. 

two points:

- if you are sending Queries that close together, the fact that 
retransmissions can overlap with responses probably means you
shouldn't be. I don't think we want to get into specificying formally
the adaptation algorithms to handle this case, but there is a point
at which making the Queries more frequent doesn't increase the
accuracy with which you track routing state.

- nothing prevents the Querying node from keeping track of more
than just the most recent Query. in that case, a Response for an
earlier Query will stop the retransmission process. however, one
would hope that the retransmission timer (T1) is longer than the
RTT, either by configuration or adaptation (see 5.3.3) so the
overlapping response/retransmission situation should be rare in
practice.

> If we require that every Query must be answered
> by a Response (in order to recover from lost Responses) I see an
> advantage of using the same query cookie for retransmissions:
> The context will be established earlier, as soon as
> the first response hits the querier, so the latter will stop the
> retransmission of queries. Subsequent responses can be dropped
> because state was already established at the querier.

that in any case is not allowed: you MUST send a Confirm for every
Response (if the Response asks for it). The retransmitted responses
may be to handle lost Confirms, and the Querying node can never 
know whether a Confirm for a particular Response arrived or not.

r.

> I guess that I overlooked something...
> 
> Regards,
>  Roland
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis