perfsonar development work

["Jeff W. Boote" <>]

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