perfsonar development work

[Maciej Glowiak <>]

Hi All,

Just a few comments to the Thread.

1. I agree that the service should specify the TTL of its Lookup 
Information. Then the LS should check if the value of TTL is between 
minimum and maximum TTL for specified LS. This ramification should be 
set by Service Administrator.
Because LSCleanup and TTLs weren't discussed at all, I just assumed the 
simplest solution implementing LS - Service Administrator sets TTL for 
all registered Lookup Information. It's implemented and works fine, and 
I think there wouldn't be much problem to implement various TTLs for 
various registered services. But it would need to discuss the way of 
sending such value. As a parameter? Or in another way - it's the 
question to our "schema" experts. :)

2. Real negotiation of TTL between the LS and service would be hard to 
achieve in our communication. It would need double communication:

   a- Service requests a preffered value of TTL
   b- Lookup service replies with its maximum/minimum/preffered value

   c- Service registers with its Lookup Information
   d- LS sends key ID in database and TTL value

Of course client may want to register Lookup Information with different 
TTL but, as Jeff said - "ls is the king" and it decides about the TTL.
Then the client is informed about the TTL value set for Lookup Information.

So I think it won't gives us so much. In all cases LS decides what value 
of TTL is set basing on its policy.

Maciej



Jeff W. Boote wrote:
> Vedrin Jeliazkov wrote:
> > 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?
>
> I did not mean to imply real negotiation. As far as I'm concerned the LS 
> is king
> here. The service can request something - but it gets whatever the LS 
> decides. I
> only intended to indicate some of the reasons the LS would change the 
> TTL from
> what was requested.
>
> The DNS analogy is illustrative. If we compare to DNS we really need to 
> talk
> about two things. 1) The TTL of the record. 2) The duration a caching DNS
> server, or resolver is willing to hold the record.
>
> The first part (TTL) is based on how long the administrator of the 
> authoritative DNS server thinks the given DNS name will be valid.
>
> The second part is based on the resources available to the given systems 
> that have looked up the information.
>
> The first part is the part that the registering service knows better 
> than the
> LS. But, the LS is the only entity that knows the second part.
>
> For a dynamic information service, this second part illustrates the 
> flexibility
> the LS needs to remain resilient. DNS does not need to worry about this 
> because
> the authoritative DNS server is generally not that dynamic in nature.
>
> > > 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. 
>
> Yes - this could get very complicated if not done correctly. But, I 
> think with sane defaults - and limits on the values allowed by a 
> higher-level LS (in the hierarchy) this can be achieved with the same 
> type of request/response model. i.e. The lower-level LS registers a 
> summary of all its content with the higher-level LS and essentially 
> specifies a TTL for the entire thing - and the higher-level indicates 
> how long it is willing to hold that information.
>
> I believe Jason's current multi-LS work already has time-outs for this 
> kind of thing. It is not exactly the same thing as the TTL of a single 
> record because the content has gone through the XSLT summary step - but 
> if we define the client interaction correctly I think it is enough. (For 
> example, this could be one reason to choose iterative or recursive 
> lookup strategies.)
>
> > Other opinions are most welcome!
>
> Yes!
>
> jeff


--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024     http://monstera.man.poznan.pl/              ||
 ====================================================================