perfsonar development work

["Vedrin Jeliazkov" <>]

Hi Jeff,

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

I agree, your arguments are valid. Actually the DNS analogy doesn't take into
account the fact that data is pushed to LS, rather than pulled by the LS,
while in DNS it's usually inverse (except for the case of dynamic DNS
updates). Perhaps this is the main reason why you have to split the authority
for TTLs between resource owners and LSes. This is somehow unfortunate,
because it certainly complicates matters a little bit (compared to the DNS
case where the source of authority is unique, rather than split between
different entities). However, I guess we'll have to live with this additional
complexity and support it in some efficient way.

Regarding the LS resilience argument, I would like to point out that a TTL
imposed by LS would protect it only from *well behaving* (compliant) perfSONAR
services. This particular protection wouldn't stop a malicious service to make
arbitrary number of registration updates, whatever TTL is chosen/advertised by
LS. The service could be just not well written/configured or even deliberately
implementing a DoS attack against LS. We should perhaps think how to protect
LSes from such floods. Actually, the DNS analogy maybe holds for this aspect
of the discussion. The main problem I see is that LSes should be probably
publicly accessible and resiliency could not be guaranteed by LS-imposed TTLs
or any kind of registration request filtering. In DNS the workaround is an
efficient backup scheme and task distribution between different levels of the
hierarchy.

Does anybody have any ideas how we could deal with this issue in our
particular case?

I think that it's very important to have an answer to this, because once LS
becomes well established and deployed, ultimately all perfSONAR services would
depend on it and therefore it would represent an interesting attack vector
against the whole infrastructure.

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

Kind regards,
Vedrin