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 one is based on how long the administrator of the authoritative DNS 
server thinks the given DNS name will be valid.
The second one is based on the resources available to the given system that have 
looked up the information.

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.

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.

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

Hopefully it can be done without real negotiation. But, it seems clear to me 
that specific servers have to be able to have some flexibility in terms of how 
often they get updates.

Specifically - there are timeouts involved in the token passing scheme of the 
multi-ls. Presumably the TTL would have to be larger than the expected time it 
takes to pass the token for convergence to take place. (If I understand 
correctly... I may not!)

> Other opinions are most welcome!

Yes!

jeff