1 / 14

Current Status of “Current” Schemas Network Measurements Working Group

Current Status of “Current” Schemas Network Measurements Working Group. Joint Techs, Salt Lake City, 16 th September 2005. Mark Leese m.j.leese@dl.ac.uk. Contents. Where we are now example recently settled issues new “queries” Where next for the “current” schemas?. Where we are.

cain-saunders
Télécharger la présentation

Current Status of “Current” Schemas Network Measurements Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Current Status of“Current” SchemasNetwork Measurements Working Group Joint Techs, Salt Lake City, 16th September 2005 Mark Leese m.j.leese@dl.ac.uk Mark Leese (Daresbury Laboratory)

  2. Contents • Where we are now • example recently settled issues • new “queries” • Where next for the “current” schemas? Mark Leese (Daresbury Laboratory)

  3. Where we are • By now everyone is familiar with the requirements (at least the basics) so should be able to follow this… • …however, this is mostly low level detail • People who like coding: wake up! • People who write documents: catch some Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz’s  Mark Leese (Daresbury Laboratory)

  4. Recently Resolved Issues (1) To list them all would have me talking to myself, so here are some examples: • Simple ones: • Add units to statistical types where appropriate. Mean RTT is still in ms. • Add attribute to timestamps to specify the format. Default is secs since epoch. • Parameters in can now be specified in any order. • The pre-defined list of parameters tags is now defined…as those already implemented. Should be adequate for most needs. Mark Leese (Daresbury Laboratory)

  5. Recently Resolved Issues (2) • Not so simple: • Request schema uses XML elements, and attributes, e.g. packetSize of 100 could be given as an element, with the units (bytes) given as an attribute. Response schema uses only elements because some tooling at the time failed to handle attributes. Schemas will be harmonised to use elements and attributes. • Traceroute…see next slide These all now need to be worked into schema, requirements doc etc. Mark Leese (Daresbury Laboratory)

  6. Recently Resolved Issues (2) <rep:routeResults> <!-- routeResults is a new structure --> <rep:section> <!-- each hop appears in section tags --> <rep:subject> <rep:path> <rep:source> <rep:host>rtvig.dl.ac.uk</rep:host> <rep:version>hostname</rep:version> </rep:source> <rep:destination> <rep:host>alan3.dl.ac.uk</rep:host> <rep:version>hostname</rep:version> </rep:source> </rep:path> </rep:subject> <rep:resultSet> <rep:timeInterval> <rep:timestamp>1103994000</rep:timestamp> </rep:timeInterval> <rep:result> <rep:delay> <rep:value>10</rep:value> <rep:units>ms</rep:units> </rep:delay> </rep:result> </rep:resultSet> <rep:order>1</rep:order> <!-- essentially hop number --> </section> hop hosthost info data for that hop Mark Leese (Daresbury Laboratory)

  7. Unresolved Issues (1) New queries, mostly from Rik (r.p.tyer@dl.ac.uk) who’s busy on a UK implementation Request Schema • In the schema, Paul has not implemented: • Parameter lists, e.g. <paramList>-t 10 –w 1024K</ParamList> • Start and end time. • Is anyone concerned/upset/about to cry? • In nm_params, why is packetType optional? Is it as a wildcard, e.g. requesting achievable bandwidth with no packetType matches against TCP and UDP? • We’ve already discussed the fact that TimeInformation in nm_requestbody isn’t mandatory (if not specified we assume defaults). With that in mind, does it make sense to say no elements of TimeInformation (timestamp + time tolerances) are mandatory. Are we making this too laden with rules of “if no value given, default to this”? Mark Leese (Daresbury Laboratory)

  8. Unresolved Issues (2) • We said that specific parameters, e.g. <numStreams> 2</numStreams> could be marked as “required” or “optional”, with optional indicating a preference. This is fine for requesting tests, but does it have meaning for querying historic data? In Both Schemas • Where can we get a standard for expressing units, e.g. “Mbps” or “Mb/s”? IETF? IEEE? • nm_params includes units for numPackets. This doesn’t make sense. Request Schema Only • Rik and I are working up to this – expect some comments in the next couple of weeks. Mark Leese (Daresbury Laboratory)

  9. Where next (1)? • “New” schemas first raised October ’04 (GGF12, Brussels) • Could have stopped “current” schema work and used existing work as a learning exercise/primer for “new” schema work… • BUT needed to stabilise “current” work to support early adopters and people who needed something now: EGEE JRA4, DANTE, Advisor… • Stabilisation in progress, but what do we do when it’s finished? • Nothing? Why should we, there’s “new” schemas coming? • easiest option, but not helpful to EGEE, Advisor etc. • Release details via NM-WG website? • Produce GGF document? • authorative & shows we’re being productive, but how onerous? Mark Leese (Daresbury Laboratory)

  10. Where next (2)? • Answer probably depends on: • available effort • expected lifetime of schemas • if anything is re-usable (e.g. business logic) • If we document the work, I’m assuming it’s: • the requirements • corresponding business logic • the Relax-NG schemas themselves! • This will ALL likely get discussed with ADs at next GGF. So I need your thoughts! Mark Leese (Daresbury Laboratory)

  11. Where next (3)? As an illustration, GGF Document Types: • Informational Documents • Interesting and useful Grid-related technology, architecture, framework, or concept • Experimental Documents • Results of Grid related experiments, implementations, or other operational experience • Community Practice Documents • Approach or process that is considered to be widely accepted by consensus and practice in the Grid community • Recommendations Documents (2 phases) • Technical specification or a particular set of guidelines for the application of a technical specification • Intended to guide interoperability and promote standard approaches Mark Leese (Daresbury Laboratory)

  12. Where next (3)? As an illustration, GGF Document Types: • Informational Documents • Interesting and useful Grid-related technology, architecture, framework, or concept • Experimental Documents • Results of Grid related experiments, implementations, or other operational experience • Community Practice Documents • Approach or process that is considered to be widely accepted by consensus and practice in the Grid community • Recommendations Documents (2 phases) • Technical specification or a particular set of guidelines for the application of a technical specification • Intended to guide interoperability and promote standard approaches Mark Leese (Daresbury Laboratory)

  13. Where next (4)? EGEE JRA4 network performance monitoring prototype (Java) Client JRA4 Mediator NM-WG DANTE perfmonit EDG WP7 Internet2 piPEs • Do we stop with documenting the schemas? • What about a reference implementation? • Again, how do we “release” this? • NM-WG website? • GGF experimental document? Mark Leese (Daresbury Laboratory)

  14. Conclusion • Stabilisation is taking time, but I/we will get there. • “Yes Mark, but when? You keep saying it will be soon!” • It will be soon  You can hopefully see we make more progress every time we have a call • In meantime, need to decide how we “release” this work? • Documentation? • NM-WG website? • ISP Area Directors can help, but we need our own thoughts first Mark Leese (Daresbury Laboratory)

More Related