RE: ENRP Server Hunt Timer

My comment below:

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Johnson Walter-CWJ002
> Sent: Friday, October 29, 2004 7:59 PM
> To: 'Thomas Dreibholz'; [email protected]
> Subject: RE: [Rserpool] ENRP Server Hunt Timer
> 
> 
> Thomas Dreibholz <mailto:[email protected]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Friday 29 October 2004 00:25, Johnson Walter-CWJ002 wrote:
> >> Currently the draft states in ENRP server hunt procedure of section
> >> 3.6 bullet item SH5 on page 21 that
> >> 
> >> SH5) If the T5-Serverhunt timer expires the following 
> should be     
> >> performed: 
> >> 
> >>       SH5.1) The endpoint MUST double the value of the 
> T5-Serverhunt
> >>       timer. SH5.2) The endpoint SHOULD stop the establishment of
> >>       associations          and connections. SH5.2) The endpoint
> >>          SHOULD repeat trying to establish an association or
> >>          connection by proceeding to step SH1.  It SHOULD 
> attempt to
> >> select a different set of transport addresses to          connect
> >> to.  
> >> 
> >> Currently the T5-Serverhunt timer keeps on doubling and there is no
> >> upper limit on this so it appears it could go on forever. It would
> >> seem reasonable to add a ceiling on the max value that the
> >> T5-Serverhunt can reach (e.g. a variable max.severhunt.value to
> >> section 5.1) or place to place a threshold of attempts to 
> make called
> >> MAX-SERVER-HUNTS in section 5.3. If either max is reached, a signal
> >> could be sent to an ASAP application of the failure to find a home
> >> ENRP server.
> > 
> > An upper limit for doubling the timeout is useful.
> > 
> > But it may be useful to keep on trying to connect to a NS even when
> > the maximum timeout has been reached, because it may be 
> better for the
> > application to wait instead of failing. For this case, the number of
> > trials must also be limited (this could be a configuration 
> option, to
> > be set by the application - I have implemented this behavior in the
> > rsplib prototype). 

I agree with the upper limit and with the idea of continuing to try (I think at the upper limited value of the timer). However it may be simpler to keep retrying forever. The application or user, can decide after certain number of failures to use ASAP (like register; name resoution etc) whether or not to shutdown. We would not need an additional configuration parameter in that case.

> > 
> > Example:
> > TimeoutLimit=4s
> > MaxTrials=100
> > 
> > Trail #1: timeout=1s
> > Trail #2: timeout=2s
> > Trail #3: timeout=4s (no more doubling)
> > Trail #4: timeout=4s
> > ...
> > Trail #100: timeout=4s  => After this trial, signal failure to the
> > user. 
> > 
> 
> 
> I agree with your proposal above.
> 
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>