Coordinates

OGF 28 - Munich, Germany

• http://ogf.org/gf/event_schedule/index.php?id=1917
• http://ogf.org/gf/event_schedule/index.php?id=1919

Agenda

• Session 1 (Outreach Session)
  • Presentation on NMC/perfSONAR
  • Status of documents
• Session 2 (Working Session)
  • Review of Hot Topics
    • Role of transport protocol (Jeff)
    • Result Codes (Roman/Slawek)
    • Chaining (Martin/Jason)
  • Document Review

Notes

• Session 1
  • Session was to focus on 'outreach', e.g. discussing the history and purpose of the NMC-WG, the current status, and the areas that we are looking to complete in the next cycle of activity.
  • Jeff Boote gave a presentation: 20100317-OGF-NMC-WG1.ppt
    • Discussion about perfSONAR, current deployments, directions
    • DFN (Andreas Hanemann) express interest in giving a presentation based on recent performance problems with software at DFN (specifically the RRDMA), will present next session.
• Session 2
  • Andreas Hanemann gave a presentation: ah-perfSONAR-issues-OGF28.pdf
    • DFN wanted to integrate the RRDMA into NOC operations (along with pSUI). Integration provided to be very difficult - performance for viewing 700 interfaces was very poor. Early testing pointed to two candidates for the problem:
      • Protocol performance (e.g. message size for getting all metadata/data was too large to handle)
      • Service performance (similar to above - but software processing by the RRDMA or pSUI was slow)
    • DFN has experienced this before, specifically with HADES and CNM. The fix was to modify the protocol into a more binary approach to deliver the data. While this solved the problem it was noted that the GUI (CNM) could have changed behavior to limit the queries/data retrieved or implemented caching to spare the server the constant queries.
    • DFN would like to see the problem addressed (either in the service or the protocol) soon. Working with PSNC/Gn3 to identify the exact cause and implement a solution. Discussion on possible causes. The service is being examined (e.g. how is the performance for a MetadataKeyRequest vs a DataRequest) as well as the new parsing libraries to encode/decode the messages. pSUI should also be examined to see if internal behavior (fetching all metadata and ranges of data) could be changed, caching can be implemented to limit how often and how much data is returned. It is noted that pSUI is parallelized to 'streamline' operations but in the long run this still puts load on the server to send back data vs smartly managing what is needed from GUIs.
    • Other slides note some problems seen at the protocol level, particularly Namespace changes - discussion on this questioned how much of an issue this really is. The namespaces of certain data items (e.g. utilization) have not changed since the first releases of perfSONAR software 4 years ago. Discussion also questioned why GUI developers can't use the LS infrastructure to locate the data they are looking for vs. relying on a set in stone query that is not nimble enough to handle a namespace change (however rare it may be).
    • Last couple of slides were related to where the documentation should live. Since this is an OGF effort, the final results will live at OGF. Links on perfsonar.net should reflect the final location.
  • Roman Lapacz went over the most recent version of the result codes document: ResultsCodes-20100303v3-jz.doc
    • Discussion on the history of the proposal, and why we need to normalize things.
    • Discussion on a proposal to include additional information via the parameters of the metadata in addition to the datum. This was declined.
    • Discussion to find and identify all possible current server codes in the framework. For this proposal to work we need to be complete. Roman/Slawek will continue this.
    • Next steps:
      • Refine the proposal to include more examples
      • Edit proposal before submitting to pS-Dev
      • Include in the NMC-Base
  • Jeff W. Boote went over the wiki TODO for the base document: NMCBase_TODO
    • Section 3
      • Need to add some more 'scoping' to the motivation, e.g. looking forward vs looking backward in this document and related documents.
      • Action: propose the 'profile' idea (SOAP over HTTP as the 'accepted' transport layer) and how it will relate to the base document. The base and the profile must be released at the same time.
    • Section 4
      • Be clear about error codes (e.g. don't say things like a certain exchange 'may' produce an error'). Protocol should be conservative in what you send and libral in what you accept.
      • New people working on this section, Piotr should be removed and add someone new (ESnet - Andy?)
      • Be clear on the semantics of the id/idRef regarding state. Don't get into chaining (leave that for NM) but note that the state has a specific scope, or if there is no implied state at all.
    • Section 5
      • Ensure we are calling chaining by the proper names (merge/operation)
      • Still some open questions on how to properly divide chaining. NM should have the ideas and examples of how to do merge/operation chaining. NMC should only add (or subtract) from the original source. Proposal to limit the use of merge chaining (will be discussed on the list - find out who is using both on the service and GUI side).
      • A please to succinctly describe the 'rules' and then show examples vs a lot of 'it may work like this' scenarios.
    • Section 6
      • David S. will look at the current result code document and give the opinions of a GUI designer.
    • Section 7
      • Possible section on extending 'data' types, not just message functionality
      • Should talk about adding new messages (not just adding to existing messages)
    • Section 11
      • Transport protocol becomes profile document

Next Meeting

• April 1 2010 - 15:00 UTC
  • Note the timeshift - the US and EU will be in Daylight time by this week.

Actions

• All: Review NMC-Base_TODO and NMC-MA_TODO, continue working on assignments
• Freek & Inder: Review and correct RFC 2119 words.
• Jason: Mail the people from Gn3 and pSPS regarding the locking down of the protocol - After OGF 28 and when base is more done.
• Slawek & Roman: continue work on Result Codes
• Jeff/Jason: Propose the idea of a transport profile document to go with the base.
• Jeff/Jason: Propose the idea of eliminating mention of merge chaining in the base.

Attachments:

ah-perfSONAR-issues-OGF28.pdf [20100317OGF28Notes/ah-perfSONAR-issues-OGF28.pdf] ResultsCodes-20100303v3-jz.doc [20100317OGF28Notes/ResultsCodes-20100303v3-jz.doc] 20100317-OGF-NMC-WG1.ppt [20100317OGF28Notes/20100317-OGF-NMC-WG1.ppt]