perfsonar development work

["Jeff W. Boote" <>]

On Aug 4, 2009, at 3:16 AM, Slawomir Trzaszczka wrote:

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

It absolute effects the aspects I mention. When you start a service,  
there is a measurable amount of time before that service is  
discoverable. Have you read the design documentation on the gLS/hLS  
interaction?

http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/doc/dLS/gLS/phase_1_color.html

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

hLS's summarize what they contain, and register that summary set to a  
gLS. The TTL effects how long that information is in the summary set  
that is registered. And, effect how often that summary set needs to be  
modified. This affects the infoset that needs to be synchronized  
across gLSs.

Note, I am not saying this change is bad. In fact, if you look back in  
the email archives I suggested that a negotiation was probably  
required between the LS and clients when they register for the TTL. I  
do however think we should have a good understanding of what systemic  
changes will take place if we were to implement this and widely deploy  
it. (In addition to prototyping and testing it to make sure it behaves  
as we expect.)



> 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

It does. Hopefully I've explained why above well enough.

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

I'm not sure you understand what I'm asking here... There is a delay  
after the service registers before a query of any gLS will be able to  
find it. (Convergence time.) I'm not asking how often a service will  
register with an hLS instance.

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