perfsonar development work

["Vedrin Jeliazkov" <>]

Hi Jeff, Ulisses,

I'm happy to see that some common view about TTLs is emerging. I have just one
further comment (please have a look below).

"Jeff W. Boote" 
<>
 wrote:

> ulisses wrote:
> > Hi Vedrin!
> > 
> > On 2006-09-07 01:58:55, Vedrin Jeliazkov wrote:
> > [...]
> > 
> >>Ulisses, I guess that by "client that registers the data" you actually
mean
> a
> >>service which registers its capabilities in LS, right? In my further
> comments
> >>below I'm assuming this.
> > 
> > 
> > yes, that's it.
> > 
> > 
> >>>Hi!
> >>>
> >>>Yes, that's right. We haven't thought about it yet.
> >>>
> >>>[ I CC-ed the e-mail to Vedrin. ]
> >>>
> >>>Vedrin, what do you think: what would be the best way (from client point 
> >>>of view) for determining such LS parameters as TTL:
> >>
> >>Maciej, if your question refers only to visualization clients (which would
> >>access the LS in a read-only mode), than I see two options:
> >>
> >>1) the client doesn't receive/process resource TTLs at all; instead, it
> >>assumes that if the LS has returned a pointer to a certain resource, then
> it's
> >>reasonable to consider the resource as being available (alive);
> >>
> >>2) the LS provides a TTL attribute for each returned resource (or set of
> >>resources) and the client is free to make its own decisions based on this
> info
> >>(e.g. cache the resource pointer while the returned TTL has not expired,
> >>consider some resource as unstable if its remaining TTL is too short,
ignore
> >>the TTL attribute, etc...).
> > 
> > 
> > [...]
> > 
> > to summarize:
> > 
> > - returning the TTL from the LS means the LS can stablish the policy. eg:
> informing
> >   that the requested TTL is too large or customizing the TTL depending on
the
> 
> >   size of the storage.
> > 
> > - specifying the TTL as a parameter to the LS will be interesting because
> each
> >   service knows it's needs, more than the LS.
> > 
> > I think that the simple, the best:
> > 
> >   the registrator sets the desired value for the TTL.
> >   the LS returns the effective TTL.
> > 
> > in think I will define this way for the TOPS notifications
> 
> I agree. The service should be able to specify the TTL it wants and the LS 
> should be able to impose policy on that TTL (A max relative to storage
issues -
> 
> and a min relative to how often it is willing to let services re-register).
> And, 
> the effective TTL should be returned to the registering service somehow so
it 
> knows how often it should re-register.

Well, this looks like a better formulated superset of what I've proposed and
I'm happy with it. You're augmenting the TTL-related functionalities with TTL
negotiation capability (between services). While such capability would be
handy to have, we should also keep in mind that it's even more complicated
(and perhaps expensive in terms of developer's time needed for
implementation), than what I proposed initially.

I'm not opposing the idea, but rather wondering why would we need such TTL
negotiation, while considering that the DNS world does fine without it. What's
the difference making such capability desirable in our case? Is it the absence
of hierarchy or something else?

> This does have some ramifications on multi-LS so I'm curious what Jason and 
> Martin think about it.

TTL negotiation + multi-LS could require a very talkative protocol, which
might also experience synchronisation/convergence problems. Again, I might be
missing something. 

Other opinions are most welcome!

Kind regards,
Vedrin