Subject: RE: [Rserpool] ENRP Server Hunt Timer

From: c s chandrashekaran-A14667 <[email-masked]>
Date: Tue, 2 Nov 2004 18:46:55 +0530

My comment below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Johnson Walter-CWJ002
> Sent: Friday, October 29, 2004 7:59 PM
> To: 'Thomas Dreibholz'; [email-masked]
> Subject: RE: [Rserpool] ENRP Server Hunt Timer
> 
> 
> Thomas Dreibholz <mailto:[email-masked]> 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-masked]
> https://www1.ietf.org/mailman/listinfo/rserpool
> 

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

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 2 Nov 2004 18:05:05 +0200

On Tuesday 02 November 2004 14:16, c s chandrashekaran-A14667 wrote:
> 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.

This would imply an asynchronous API, e.g. the user calls 
StartNameResolution(), which initiates the name resolution in background and 
returns immediately. Finally, the user application is notified - by signal (a 
bad idea!) or callback - and then calls a function GetNameResolutionResult() 
- or the user aborts the name resolution when he decides to have waited long 
enough. Example:

void callback()
{
   Notify main program that name resolution has been successful
}

ok = StartNameResolution();
if(!ok) {
   cerr << "ERROR: Unable to initiate name resolution" << endl;
   exit(1);
}
Start a timer -> nameResolutionCallback
...
while(...) {
   if(Name Resolution Event) {
      Name resolution successful!
   }
   if(Timer Event) {
      Name resolution failed!
   }
   ...
}

Probably, the program also has to care for thread safety in the callback 
function!

An asynchronous API is quite complicated. Giving a maximum number of trials 
directly to a NameResolution() function is much easier to use and much nearer 
to the existing DNS name resolution API. Example:

result = NameResolution("MyPoolHandle", 10 Trials)
if(result == NULL) {
   cerr << "ERROR: Name resolution failed!" << endl;
   exit(1);
}

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 02 Nov 2004 11:52:53 -0600

Hi,

A general comments to this timer discussion.

There are a lot of useful stuff and interesting details if we look at rserpool from an 
implementation's perspective, such as many things being talked about in this thread. But not 
necessarily all of them should be documented in the spec. IMO, only those details which, if 
ignored, would 1) cause interoperability problems, 2) impact the network in a negative way, 
or 3) undo a designed feature should be documented.

Moreover, the spec should always be written conservatively since it is a known fact that the 
implementations are always the ones that push the envelop of aggressiveness.

With the above in mind, I would NOT recommend to put text suggesting the use of a ceiling 
for the timer and continuous try at the ceiling. These are aggressive behaviors and very 
likely many implementors will try to do without the spec asking them to. There are 
aggressive since they may negatively impact the network if the ceiling is set too low or the 
endpoint just refuses to give up trying forever.

If we really feel that the ceiling and continuous try are essential to rserpool operation 
and must be supported (I haven't been convinced that they are), then we should have text in 
the spec to explain it (including how they are essential to rserpool). And it must say some 
thing like - if the ceiling is used, it MUST NOT be too small. Or if continuous try is used, 
it MUST come with a mechanism that the endpoint will give up at some point. IETF won't want 
some endpoints injecting infinite packets into the network.

regards,
-Qiaobing