perfsonar development work

["Jeff W. Boote" <>]

Slawomir, other interested parties,

Since you have been looking at adding the LsTTL parameter, I have some questions for you regarding what it means for the entire LS system (not just the single hLS server).

How long after a service registers with an hLS, should you expect to be able to see its summary in all gLS instances?

How long after a service goes away, would you expect traces of it it to disappear from all gLS instances?

How long after it goes away, would you expect to have all traces of it removed from the hLS instances it registered to?

As we have deployed many, many hLS instances now - I can tell you that it is very important to be able to manage user expectations regarding service availability. This is why I'm curious how this new parameter effects the answers to the questions above. And, I wonder if we should impose limits on the valid ranges of this new parameter. (And, I wonder where those limits should be imposed if indeed there should be limits.)

thanks,

jeff

On Jul 6, 2009, at 9:23 AM, Jeff W. Boote wrote:

Clearly there are issues to discuss here.

On Jul 6, 2009, at 5:14 AM, Michael Bischoff wrote:

The only objection I see would be in the case of the LS only supporting high TTL values and
it's common that the service 'goes away' (thus leading to a lot of requests going nowhere)
But in practice this problem shouldn't really be a problem since: a LS implementation
probably favours discarding information as quickly as possible and also if we factor in
'locality' the ones affected the most will be the ones who also maintain the service/LS.

In practice, this is a real problem. For the global discovery system to work correctly, it is important to understand how long it will take to converge information from leaf LSs into the global state. If there are not pre-defined limits on the extents of things like the TTL value, it is not possible to model that from a global perspective.  This needs to be considered not only on how it affects the specific client/server involved, but on how it affects the global state of the system.

In general, I don't have a lot of opinion on specifically how this information is encoded in the request/response messages. The individual service developers are going to have far more opinions on that. But, I do want to think about how this affects the service discovery system as a whole. And as I implied before, I do want some time to consider if there are more session-state parameters that should be considered together with this.

I would like a couple of weeks to think about this since we are in the middle of a release cycle and don't have time to devote to it until late July. (Is there a specific time constraint on the EU side pushing that this happen quickly?)

thanks,

jeff