Info

Information Services (IS) Working Group
July 21, 2009,
12:30 PM - 1:50 PM

Location: TBD
University Place Conference Center and Hotel
850 West Michigan Street
Indianapolis, IN 46202

Session Info

Agenda

  • Query Language of UNIS
  • Document discussion
  • NML update
  • Discussion of security models
  • Misc Topics

Attendees

  • Jason Zurawski - Internet2
  • Martin Swany - University of Delaware
  • Andy Lake - Internet2
  • Chris Small - GRNOC
  • Evangelos Chaniotakis - ESnet

Notes

Query Language of UNIS

Initial discussion started with a review of why the existing perfSONAR tools rely on XQuery/XPath as the primary query mechanism (N.B. initial database design featured native storage, hence native queries were used). Some questions on if this was how UNIS will continue to do things, and some thoughts on what it means to write your own query language. It was noted that it is very hard to get a general purpose query language correct - and even harder to get other groups to adopt what you create. The bottom line is that whatever language is used needs to have logical/operator functions, should be general enough to fit the current perfSONAR/DCN/SDN definitions for service and topology, and should be nimble enough to adapt to future needs.

Some mention of exploring a REST-like API (may make more sense for IS applications - persistent URIs for resources). Would need to be explored in more depth. May be complicated with the lifetimes that are assigned to elements.

Document discussion

Jason/Martin presented the work that Marcos has started regarding the UNIS document (see attachment on this page). Current document consists of use cases from this group. Work in the next couple of months will:

  • Expand use cases
  • Add current/future plans for perfSONAR/DCN/SDN information services
  • Release drafts for WG review

NML update

Discussion about last NML face to face (OGF in Chapel Hill), and where the current NML schema fits with perfSONAR/DCN/SDN/IS-WG work. Bottom line is that NML is a hybrid of the initial perfSONAR and RDF descriptions. An NML schema is in progress (Martin/Freek/Jerone/Lars - see Gridforge for updates). Jason has prepared a 'legacy' document that describes the perfSONAR schemata that should be used as an informational in the NML - has not been accepted by this group yet but may be before the next OGF (October).

Discussion of security models

Re-starting of a discussion that happens almost every call. DNSSEC features a signature per resource. This model may be hard to scale in UNIS land. We could also just sign the entire database for a given service - but one change means needing to recompute the entire signature (not optimal when the datasets change so fast). Also don't want to get into trying to sign a 'zone' similar to DNSSEC.

Discussion goes back to trust model. Transitive seems to work best for us: If I trust A, and A trusts B, I should trust B. Question was raised about who/what constitutes a 'zone' in this world.

Simple strawman was discussed regarding a chain of signatures:

  • A service registers with an IS
  • IS Checks signature of service and data that was sent.
  • IS then summarizes and generate a new signature for it's data set.

Misc Topics

Martin mentioned he was reading PostgreSQL documentation and noted that support for CIDR datatypes is expanding. Noted that the format to store ws always there, querying may be hard (does not know the extent of the support). Worth exploring for future UNIS projects.

Martin/Jason discussed current gLS implementation and some optimization strategies (also some ways to remove reliance on XML database). One topic that has been mentioned before is an in-memory RADIX tree that is updated constantly with IP summarization information. Would depend on how large the tree is, and how well the data structure can be managed by Perl. Jason will experiment with Marco's new work in the Fall before and leading up to perfSONAR-PS 3.2.

Larger discussion on caching begins - hybrid approach to gLS organization where only source data lives as XML, use lots of caching (MySQL/PostgreSQL/SQLite/BDB) for fast lookups, namely the information we yank out (eventTypes, domains, keywords). Should create more 'index' values beyond the 4 we have now.

  • No labels