perfsonar development work

[Slawomir Trzaszczka <>]

Hi Jeff, 

I would like to notice that LsTTL implementation is a kind of
'prototype'. This implementation doesn't change any aspects of
functionality. LsTTL is optional and doesn't have any influence to
protocol. LsTTL parameter should be limited. The 
restriction should occur in service.


Currently, GLS and HLS doesn't have any synchronization. HLS can have
any TTL parameter. If few HLSs have different TTL, synchronization
between them and GLS doesn't occur. 


On Mon, 2009-08-03 at 10:33 -0600, Jeff W. Boote wrote:
> 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).

optional lsTTl parameter doesn't have any influence on gls/hls
> 
> How long after a service registers with an hLS, should you expect to
> be able to see its summary in all gLS instances?
> 

it is interval parameter defined in service (global for all elements)

> 
> 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
> 
> 
Regards,

Slawek