Subject: RE: [NSIS] about refresh query

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Sep 2005 17:09:38 +0100

Hi Jia Jia,

the crucial phrase in the NTLP spec is in section 4.3:

  "It is the responsibility of the Querying node to generate
   a GIMPS-Query message before this timer expires, if it believes that
   the flow is still active; otherwise, the Responding node may delete
   the state."

In other words, it's intended to be up to the implementor; the -08
version will say this in slightly more formal terms in the state
machines description (section 6.2). Your formula seems quite
reasonable to me; a more cautious implementor might also include
some jitter to avoid network synchronisation problems.

It would be a good wg last call point to discuss exactly how 
prescriptive the specification should be on this sort of issue.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 26 September 2005 15:14
> To: [email-masked]
> Subject: [NSIS] about refresh query
> 
> 
> 
> Dear colleagues, I am implementing the background maintenance 
> support for GIST
> now, which needs to send  refresh Query Messages after the 
> Routing State is
> installed at the Q-node. The NTLP draft specifies the 
> validality time in the
> NLI object, which means that the Query-node or Response-node 
> will remove the
> Routing State from its routing table if this node doesn't 
> receive any refresh
> Query/Response messages during the validality time period. My 
> question is that:
> 
> 
> What is the timeout value I should set for the Timer of 
> sending the refresh
> Query message? Obviously, it is not appropriate that the 
> timeout value is set
> to the validality time and it seems that the ntlp draft 
> doesn't notice this
> issue. Now I set the timeout for the Timer of sending refresh 
> query message as
> follows: timeout = min(ValidalityTime of Q-node, ValidalityTime of
> R-node)*fraction_factor, ( fraction_factor= 3/4, currently). 
> Any comments are
> welcome.
> 
> Best Regards
> 
> Jia Jia
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Thu, 29 Sep 2005 10:28:19 +0100

Hi, Robert,

Thanks for your prompt reply. I have another question to ask.

In section 5.3.3, the draft describes the retransmission algorithms
against the losses of Query, Response and Confirm messages. However, 
It seems that the draft doesn't specify when the retransmission algorithms 
should be used (correct me if I am wrong).
I know the retransmission algorithms should be used in the case that
the Q-node needs to discover its downstream peer by sending a new Query
message.
My question is that:

should the retransmission algorithms also be used against the loss of
refresh Query message? As we know, sending refresh Query message involves 
validality times of both Q-node and R-node. Then, how should the T1 and T2 
timeout values (see section 5.3.3) be chosen in the case of retransmitting
refresh 
Query message? 

My opinion is that we don't need to re-send any refresh Query message and just
let 
the routing state removed if any refresh Query/response message is lost on the
way.
And then, the Q-node can have a new handshake process if it needs to send any
message to
its downstream peer afterwards. Any comments are welcome.

Cheers,

jia jia