Subject: [Rserpool] ENRP Server Hunt Timer

From: Johnson Walter-CWJ002 <[email-masked]>
Date: Thu, 28 Oct 2004 17:25:20 -0500

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. 

If people feel this is a good change I can craft the text for it.

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

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 29 Oct 2004 11:49:42 +0200

On Friday 29 October 2004 00:25, Johnson Walter-CWJ002 wrote:
> 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).

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.

Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================