Subject: [NSIS] Re: Retransmitted Queries

From: Roland Bless <[email-masked]>
Date: Mon, 05 Mar 2007 16:11:07 +0100

Hi Robert,

Hancock, Robert wrote:
> hi roland,
> 
> sorry for the delayed reply. 

No problem as long as there is one :-)

> 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).

That's ok.

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

Ok. See below.

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

I don't get this point. In fact we have seen such behavior
in our stress tests due to backlogging effects and so on.

> 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

That is a good point and I think that it's worth mentioning
in the GIST spec.

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

You are right.

Thanks,
 Roland

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Mar 2007 09:56:01 -0000

hi roland,

inline below: 

cheers,

robert h.

> Sent: 05 March 2007 15:11
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: Retransmitted Queries
> 
> Hi Robert,
> 
> Hancock, Robert wrote:
> > hi roland,
> > 
> > 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.
> > 
> 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).
> 
> That's ok.
> 
> >> 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:
> > 
> I don't get this point. In fact we have seen such behavior in 
> our stress tests due to backlogging effects and so on.

can you outline the message sequence? i'm not saying that this
is logically impossible; i'm saying that if it happens, everyone
would benefit if some timers were backed off to avoid it. in fact,
there are some notes on this added in the latest version (section
4.4.4). in other words, my claim is that the protocol should not
be optimised to handle this circumstance - rather, there should 
be implementation guidance to avoid this circumstance in the first
place.

> 
> > the adaptation algorithms to handle this case, but there is 
> a point at 
> > which making the Queries more frequent doesn't increase the 
> accuracy 
> > - 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
> 

added issue
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue207

> 
> > 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.
> > 
> > may be to handle lost Confirms, and the Querying node can 
> never know 
> > whether a Confirm for a particular Response arrived or not.
> 
> You are right.
> 
> Thanks,
>  Roland
> 
>