When

Starting Time: August 31, 2009 at 1:00 PM, US/Eastern

Dial In Information

To join both the web and audio conference (recommended), click here: https://edial.internet2.edu/call/0187242
If you only want to participate in the audio conference, you may dial in with the following numbers:
Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only)
Enter access code: 0187242

Agenda

  • IS-WG Document (UNIS)
  • UNIS Tie in w/ OGF Groups
  • perfSONAR gLS/hLS Scalability
  • NML document migration
  • Additional topics

Attendees

  • Attending:
    • Marcos - UDel
    • Jason - Internet2
    • Martin - UDel
    • Aaron - Internet2
    • Ezra - UDel
    • Andy - Internet2

Notes

IS-WG Document (UNIS)

The initial draft of the UNIS document is posted here .

JZ will be doing an edit pass this week and uploading a new version. Currently the document contains the compiled use cases that this group started here .

UNIS Tie in w/ OGF Groups

MS brought up recent OGF WG activities, namely NML and NSI, that are encroaching on work done in the IS-WG. A particular topic that requires action in this WG is the adoption of the new style for URNs. To refresh:

URNs are globally unique identifiers that can be used to identify network elements no matter what technology they are.

The identifiers are constructed as Uniform Resource Names (URNs) in the RFC 2141. The namespace for the URN is ogf and the subnamespace is network. All identifiers must begin with urn:ogf:network: in this format. The remainder of the identifier consists of a series of name and value pairs. These fields provide the hierarchy and the flexibility offered by this schema.

There are five major fields defined for network entities:

  • domain
  • node
  • port
  • link
  • path
  • service

An example of an old-style URN (still in use today for perfSONAR and DCN applications):

urn:ogf:network:domain=internet2.edu:node=packrat:port=eth0

The new format is similar, but takes away much of the structure. This proposed format still relies on a domain name, but everything after the domain should be viewed as an opaque glob e.g. this information may appear structured but should not be treated this way by services or parsers attempting to gain meaning form the urn. Examples:

urn:ogf:network:<dns name>:<opaque part>

Examples:

urn:ogf:network:internet2.edu:75dbd1af3c924906f2f4355a09105ed2
urn:ogf:network:internet2.edu:CHIC_1-A-1-1

AB and AL agreed they could live with this, but the tooling is a long way from supporting it. AL estimates this would not be considered in DCN/OSCARS/IDC until after 0.7 release (2010). AB did not give a time estimate, but suggested that perfSONAR support depends on perfSONAR buy-in as well as DCN/OSCARS/IDC support. This may not happen till mid 2010.

MS proposes a short recommendation document to show the IS-WG supports the NML/NSI WGs choice of this.

AB is concerned that there are other groups working in the same areas as the IS-WG (NSI/NML, specifically). He feels that if the groups all produce different recommendations, it could result in non-interoperable frameworks. MS and JZ point out that these are groups external to the IS-WG, and in a completely different forum, the OGF. The IS-WG is an NTAC chartered group (charter here ) that should work with the external groups in the standardization bodies. MS suggested working more closely with these groups to work toward compatibility between the resulting recommendations.

perfSONAR gLS/hLS Scalability

MP and JZ are beginning some scalability trials for the perfSONAR Information Services. *MP*s current testbed:

  • gLS on a server at UDel
  • hLS on a different server at UDel
  • fake service script that registers data to the hLS

The goal is to find the limits of:

  • How many metadata elements per service can an hLS support comfortably.
  • How many services per hLS (with consideration to the first point) can be supported comfortably
  • How many hLSs can a gLS support
  • How many gLSs are needed to support the load of the previous points

Other considerations:

  • How frequently should a gLS synchronize with peers
  • How often should an hLS register with a gLS or gLSs
  • How many gLSs should an hLS register with
  • How often should a gLS/hLS summarize internal data
  • How often should a service register with a hLS
  • Should the time between service to hLS registration be negotiable (e.g. the data TTL)?
  • Should the time between hLS to gLS registration be negotiable (e.g. the data TTL)?

JZ suggests to MP that before he gets too far he consider moving the experiement to planet lab to explore the scalability aspects. MS will have the action of setting up a planet lab slice.

JZ, MS, and MP discuss the reason for the sudden interest in testing. Some members of the pS community are skeptical of the design of the hLS/gLS currently. These individuals are convinced there is a design flaw, but rarely suggest ways to fix the perceived shortcomings. The testing is a way to prove the scalability limits if the current setup.

MS discusses the JXTA protocol and it's query mechanism (flooding with non-deterministic choices). This is similar to gnutella. MS and MP will explore this more.

MS also brings up what RDF uses for discovery (e.g. follow the web of descriptions in RDF files).

MS and JZ muse on DHTs. JZ dusts off old findings from a previous paper: DHTs are inherently unreliable since we would need to rely on the running of DHTs servers from other individuals (e.g. planetlab runs opendht) or we would need to buy resources world wide to do so on our own. DHTs also allow a 1024 bit 'payload', would only be useful as an index instead of a storage mechanism.

NML document migration

MS discusses a document prepared by JZ, now being looked at by EK, that was originally meant for the NML-WG. Located here. MS thinks that since the NML-WG balked at including this, it should become part of the UNIS document, or become a different IS-WG product.

JZ agrees - has the action of cleaning it up and giving it to the group.

Conclusions

  • ACTION - Jason - Edit UNIS document and upload a new version
  • ACTION - Jason - Edit NML-WG document for IS-WG
  • ACTION - Martin - Make PL slice for Marcos
  • ACTION - Marcos - gLS/hLS scalability testing
  • ACTION - Martin/Marcos - Research RDF/DHT/JXTA as possible discovery/query alternatives.
  • ACTION - Martin/Jason/Aaron/Andy - Prepare a short IS-WG document on URNs
  • No labels