Subject: RE: [NSIS]about retransmission of fresh query messages

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Oct 2005 16:01:11 +0100

Hi Jia Jia,

There are a number of semi-related issues here.

1. Whether a Confirm is sent or not depends precisely on the R-flag
setting in the Response. This is implied in a number of places, but
is only really explicit in A.1, which is probably a bit late.
Added
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue70

2. To be more explicit that the retransmission rules apply to all
Query messages (not just the initial one), I would update 5.3.3. 
This could also indicate something about what values to use for
T1/T2 in this case, although I am not sure exactly what to say here.

- Same T1/T2 as for initial Query seems reasonable (these are in any
case implementation chosen), in the absence of any other constraints
(but see below)

- I don't see these as being tied to the RS-Validity time. T1/T2 are
about trading off the the reliability of packet transfer between 
particular nodes and the urgency of a particular message; the
RS-Validity
time is about how likely it is for a path to change. You can imagine
scenarios where one could be much larger than the other, either way
round.
So, I would leave this open.

- The question about the T1/T2 setting vs. the Timeout value from 
SendMessage is a good one. Strictly these are different concepts, since
T1/T2 apply only to Query messages, whereas the Timeout applies to 
all messages. But it seems reasonable to say that T2 SHOULD be chosen 
to be less than the Timeout requested for the message.

I've added all this as another issue:
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue71

Cheers,

Robert H.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 03 October 2005 14:21
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [NSIS]about retransmission of fresh query messages
> 
> 
> Hi, Robert,
> 
> Thank you for your reply, Please see my comments below. 
> 
> Quoting "Hancock, Robert" <[email-masked]>:
> 
> > Hi Jia Jia,
> > 
> > You raise a valid question about 'refresh' handling.
> > Essentially I think there is a design choice which could
> > go two ways:
> > a) handle refresh messages differently (no need for retransmission,
> > just assume that a refresh will get through before routing state
> > expires), or
> > b) handle all Query messages the same way (retransmission with
> > an exponential backoff).
> > 
> > The design choice in GIST is (b). This isn't explicit in 5.3.3
> > but is (I hope) in 6.2, which is supposed to capture this sort
> > of detail more precisely. 
> > 
> > So, one question would be whether this needs to be explained
> > better.
> 
> 
> Section 6.2 of GIST does illustrate the design choice (b) 
> better. However,
> I still think that it needs to be explained more clearly and 
> in more details.
> For instance, The query node state machine in Fig.6 (section 
> 6.2) indicates
> that,when the query node is at the "Awaiting Refresh" state 
> and receives a
> ResponseMessage, it still needs to check whether a Confirm is 
> required and send
> the Confirm if required. I think maybe it could be better if 
> this information
> is also mentioned at Section 4.4.3 "State Maintenance Procedures"?
> 
> Moreover, I didn't find the clear information about how a 
> query node can
> determine whether a Confirm is required or not in the draft 
> although the GIST
> draft did imply that the query node can determine that based 
> on the R flag of
> the Common Header of the received Response message.  
> 
> 
> > The other question would be whether the design decision is
> > correct in the first place. Given that we have a retransmission
> > mechanism for the initial Query, I think it is simpler to use
> > it for the refresh case also. Otherwise, there is a more 
> > complex analysis needed for the timer setting for sending
> > refresh messages to account for the fact that one may be lost;
> > it also becomes trickier thinking about the fact that the
> > RS-validity time can be changed by either end.
> 
> I understand the design decision of treating all the query 
> messages in the same
> way to eliminate the complex analysis. I notice in Fig. 6 of 
> section 6.2 that 
> the "Awaiting Response" state and the "Awaiting Refresh" 
> state use the same rule
> for their retransmission. Does it mean that the "Awaiting 
> Refresh" state will
> set the same T1 and T2 timeout values (for retransmission 
> algorithm) as the
> "Awaiting Response" state does, without considering the 
> Validality Time of both
> nodes at all? 
> 
> In addition, when a NSLP needs the GIST to send one NSLP 
> message, it indicates a
> Timeout value to the GIST, which specifies the length of time 
> GIST should
> attempt to send this message before indicating an error. 
> Then, My question is:
> what is the relationship between the T2 timeout value of the 
> retransmission
> algorithm and this NSLP Timeout value? 
> 
> Fig. 6 of section 6.2 shows that, if the number of Queries 
> sent has reached the
> threshold and no Response message is received, the GIST will 
> indicate NO
> Response error to NSLP. 
> However, as mentioned before, when the NSLP Timeout value is 
> reached and the
> NSLP data was not sent out, the GIST should indicate an error 
> to the NSLP. Is
> there any better way to relate the T2 value with the NSLP 
> Timeout value and
> then to report only one error to the NSLP instead of two?
>  
> > (So, a third question would be whether more of this rationale
> > should be captured.)
>  
>  Cheers,
>  
>  Jia Jia
> 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> > > Sent: 29 September 2005 11:28
> > > To: Hancock, Robert
> > > Cc: [email-masked]
> > > Subject: [NSIS]about retransmission of fresh query messages
> > > 
> > > 
> > > 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
> > > 
> > > Quoting "Hancock, Robert" <[email-masked]>:
> > > 
> > > > 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
> 

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