[nm-wg] notes from NM-WG session at GGF12 - Bruxelles

["Leese, MJ (Mark)" <M.J.Leese@dl.ac.uk>]

Hi folks,

Prior to our phone call today here are the notes from the day long NM-WG
session at GGF12 in Brussels. Richard will post the presentations on the
NM-WG website in the next few days (http://www-didc.lbl.gov/NMWG/) when
hopefully the notes will make a bit more sense. Please let me know if I've
made any mistakes.

Many thanks to those that could make it. For those that were unable to, I
think we had a successful meeting, with even the rain and Belgian beer
fuelled hangover unable to dampen the enthusiasm :)

There's a lot of text below (don't say I didn't give you the meeting
verbatim :) but the main point to come out the meeting is that everyone
liked the idea of Dan and Martin's new schema framework. This now poses the
big question of what we do with the current schemas. The choices seem to be:
a. shelve current schema work and concentrate on the new versions proposed
by Dan and Martin
b. continue work on the current schemas, knowing they will be superceded at
a later date (and warning potential users of this) using the current schemas
to finalise issues such as which timestamp we use, and to allow enthusiastic
people (e.g. DANTE and EGEE) to put performance data publishing WS
infrastructures in place

Hopefully speak to you, err, right now!

Cheers,

Mark.



NM-WG session at GGF12, Brussels: Tuesday 21st September 2004, 11:00-19:30
--------------------------------------------------------------------------

Present: Awaiting copy of the sign-in sheet, but from memory: Marinho
Barcellos (BT & Manchester Uni); Iosif Legrand (Caltech); Loukik Kudarimoti
(Dante); Mark Leese (Daresbury Laboratory); Eric Boyd, Jeff Boote and Matt
Zekauskas (Internet2); Dan Gunter (LBL); Richard Hughes-Jones (Manchester
Uni); Tanya Brethour (NSCA);  Paul Mealor (UCL); Martin Swany (Uni of
Delaware) and Thilo Kielmann (Vrije Universiteit, Amsterdam).

Contents: The meeting consisted of a series of presentations (to be made
available via the NM-WG webpage) and concluded with an informal discussion
session.

Resulting Actions:

* Chairs to action someone to look at adding custom tags to schemas.
+ Repeated sections (sequences) in messages broke Warren's Perl SOAP::Lite
code that processed requests. Dan and Martin will mail a suggested work
around to the list.
+ Paul and Loukik to share their schema validation Java code with Tanya
who's also using Java but with the default RPC-Encoded binding.
+ Warren to try and implement a document-literal version of his NM-WG
interface for piPEs, in Perl.




1. Request Schema Update: Mark Leese

After opening the meeting, Mark presented an update on the request schema
work.

Iosef asked if anything had been done about replicating data? He thinks we
will have so many clients/consumers for network performance data that we
won't be able to satify them all, hence the need for replication.
Mark replied that we've thought about it, but:
* existing monitoring architectures are all varied:
	+ in the UK the plan is for monitoring points to publish into one
database that has WS access
	+ the European model (EDG WP7) is to use R-GMA, looking like one
database although the data may be distributed
	+ in some US work (SLAC he though) data is only available at the
node on which it's measured
* also wanted to see what other people (e.g. WSRF) were doing in respect to
issue like discovery of services (location of publication services, or
location of individual nodes if data only available from individual
monitoring points)
* we were planning on providing access to the data (getting it available by
WS so clients can get to it) then worrying about data replication.
Especially since replication would appear to be beyond our scope. It's
really a completely separate issue, and will be shared by lots of groups.
This isn't specific to NM-WG.

One of the outstanding issues raised what allowing custom tags to be added:
Richard: Yes, we need the schemas to be extensible. We can't possibly hope
to cover all things that people will want now and in the future.
Thilo: thinks it's easily done if you require people using custom tags to
produce some kind of description (like a plug-in) for their extension.
Need to action someone to look at this.

Someone from Asia-Pac raised the issue of needing to define errors, e.g. you
send request for a test, but the IP address is  wrong.
Mark: this should either be covered by Dan's "error" presentation or under
the  business logic (e.g. system should return "malformed request" message).
Eric: We do not yet have any business logic. The request schema is the input
API. The response schema + errors are the output API. The business logic is
to come.

Marinho: What does the group do? Are there any references to IETF IPPM
group?
Martin: We made references to IPPM in the hierarchy document
Dan: And the IPPM is referenced from the web page
Mark: The main aim of group is to look at how network monitoring data can be
published for the Grid, *not* how measurements should be made. NMA-RG (and
we a little) will look at how the data can be used.




2. Review of the Current Response Schema: Dan Gunter

No notes. Everyone obviously happy ;-)




3. Note on Time Stamps & Name Spaces: Dan

This discussion was needed as we've used timestamps for every time related
measurement value. But we have a choice over what format to use:

+ NTP timestamp: 64bit number, plus a resolution, plus accuracy. The
accuracy isn't really defined, as it rather depends upon your system.
+ the in-built XML time type
+ seconds since the epoch

There was some discussion about single source timestamps (SST): a timestamp
that comes from a particular source, but hasn't really got any relation to
the outside world. Comes with an identifying name, so you know you're
dealing with the same SST.
Richard: You can't really relate between a SST and a real timestamp though
can you?
Dan: You can, it's how NTP works: there's a certain accuracy limit.

Thilo doesn't see need for human readable timestamp. On the wire, you just
want a number.
Dan counters that it's what the XML world is using (it's the default XML
time format) and it makes debugging much easier. We shouldn't be worried
about compactness: XML is by its very nature not compact.
Thilo then raises the possibility of having "normal" and "debug" modes. Are
there other fields where we would want a different formats for debugging and
efficiency?

Richard: rejects the argument that we shouldn't specify a particular format,
because everything else is a specification anyway.
Eric: is worried that being too prescriptive ("You are required to use this
format...") will scare people off ("I don't want to use their schema because
it will make me use this format, I don't want to...").

Conclusion: The formats are left in for now, with the proviso that if they
aren't used without good reason then they can  be removed at a later date.
They won't be removed if they're in use, in which case you make an argument
that they are required.




4. Implementation of the Request Schema in piPEs: Eric Boyd for Warren
Matthews

Warren has produced a demo system that uses the request system to request
on-demand tests, using the 9th January 2004 request schema.

* The demo is at http://abilene.internet2.edu/ami/services/demo.cgi if you
have access.
* You can also see
http://abilene.internet2.edu/ami/services/webservices.html
* An example Java client is available
* The demo interface is a Perl CGI script that dumps the incoming response
from the test system to the screen
* It works for pings and BWCTL
* It implements the reportAll attribute, so many many of the test parameters
used are reported back
* Next week there will be a new version of BWCTL that allows third party
measurements
* Discovery doesn't exist yet, Internet2 solve the problem with a list of
available services
* The next step is intercontinental tests

Eric said that:

* The business logic will be captured in a document. Implementation
experiences will go on web page - they cannot go in the doc, or the business
logic will never get finished.
* People are actively encouraged to get involved


Warren also had some comments on the request schema:

* Apparently, an address can have a port, by virtue of the presence of
networkMeasurementRequest.request.subject.node.address.port. Buy why?:
We're not sure, but this needs to be cleaned up, either by defining it as
meaning something, or removing it.

* You can have a source which is IPv4 and a destination which is IPv6. Is
this legal or valid?:
Jeff argued that there are legal ways in which v4 and v6 can talk to each
other. We are also not limited to IP. So we need address families. Addresses
should have an address type field instead of a version
(networkMeasurementRequest.request.subject.path.version).

It's up to the receiver to reject things if it gets invalid requests.

* For networkMeasurementRequest.request.methodology.endpoint what is the
purpose of option endpoint=none?:
Err, Eric didn't understand Warren's point

* Repeated sections (sequences) broke Warren's Perl SOAP::Lite
implementation:
Dan though this was seriously broken, but was not happy about changing the
schema because of an implementation issue. Eric argued that loads of people
will use SOAP::Lite.

Dan and Martin will mail a suggested work around to the list.

* How do you request a test that includes the disk, e.g. disk-to-disk iperf
test?:
No on in the audience was sure. Someone suggested that it doesn't make sense
to have an attribute like "includeDisk" in the request, but others
disagreed.




5. Demo of the Internet2-Netlogger database: Dan

* Dan showed the demo, implemented in python, at:
http://test.dsd.lbl.gov/snm/
* It is not designed to demo the current schemas, but show alternatives
aspects for those schemas
* Someone from Asia-Pac asked about the feasibility of using a DB in
practice. Jeff responded that it was not really storing much data. You could
store two year's worth in there without any problems. If there was more
data, you could have a fresh DB for each year.
* xQuery isn't used as it needs more server side support




6. Reconciling the Request and Response Schemas: Dan

* This should mostly be additions.
* The Methodology section use regular expression types symbols like * and ?.
There's a ? in the request schema's Methodology section but a + in that of
the response schema. It should be *, meaning 0 or more.
* Time related fields should be timestamps in the request schema, not
doubles
* Once we've reconciled the schemas then we can share components, but we
need a sourcing system (e.g. CVS) first.
* Eric suggested that we make the reconciled version the next version, then
make any changes arising from this meeting. So...

Resulting actions:
i. reconcile request and response schemas (inc. sharing components)
ii. implement changes arising from this meeting




7. Simplified Request/Response Framework: Martin Swany

Not lots of discussion, other than lots of positive noises. See presentation
for more info.




8. Verification of Schema, Demo of Schemas Working, and How it is Working:
Paul Mealor & Loukik Kudarimoti

We now have example code (in Java) to validate NM-WG requests against the
schema using the document-literal SOAP binding.

Resulting actions:
i. Paul and Loukik to share their code with Tanya who's using Java but with
the default RPC-Encoded binding.
ii. Warren to try and implement doc-literal for piPEs in Perl. This should
also solve his repeated XML elements problem, as DOM supports these. This
ties in with Richard wanting to see some more implemations, in different
languages, so we know soon if we are going to have problems.




9. How to Handle Errors: Dan

* Whichever may we go, it will hopefully be implementation agnostic.
* Some standards are appearing for describing faults, e.g. The OASIS WSRF-TC
already has a structure.

The initial suggestion seemed to be for a set of base calls, giving basic
fault information.
* The error code field could be anything: for POSIX it would be a textual
representation of the field.
* Matt: should use just three errors to start with: disallowed, not
available and broken.
* Matt: NMWG should not define particular code types. Out of our scope.
* Jeff: suggested layer inbetween the client and the system giving just the
errorcode. One that gives fuller explanations, e.g. "SQL  error: bad table
name", or one describing general error types:
	+ system failure (could be disc, or anything else)
	+ internal failure
	+ access denied
	+ lack of resources
If application then wants to give further details, then they can, using some
kind of hiearchy:
	
	you have error
	|
	you have error: access denied
	|
	you have error: unknown user/bad password/invalid certificate/not
allowed at this time of day...




For the last 90 minutes, a smaller group (Dan, Eric, Jeff, Iosif, Loukik,
Mark, Martin, Matt, Paul, Richard, and Tanya) gathered at the front of the
room to brainstorm the next steps.

The group brainstormed the following list of possible activities, and then
discussed which should be done. Only those with a * have so far been agreed
as necessary.

1.	Create nmwg SourceForge
	a. Richard to check if GridForge appropriate
	b. Eric to create SourceForge if not
*2.	Work on error/fault codes document
3.	Add the small changes from 10th and 31st August phone calls, and
address Warren's comments on the version of the request schema that he's
used
4.	Reconcile request and publication schemas, including settling
outstanding issues (e.g. batching)
5.	Pull out the request-publication commonalities into sharable
components
	a. get both schemas to reference timestamp sub-schema
*6.	Share Paul/Loukik's doc-literal Java code with Tanya (for Advisor)
7.	Ask Warren to implement doc-literal in Perl for piPEs
*8.	Follow up Dan and Martin's new framework suggestions
	a. enhance request-publication requirements
	b. strawman schema to implement those requirements
	c. example of using that schema
*9.	Validate schemas work
	a. get a system to produce NM-WG compliant results message
	b. get requestor to validate incoming NM-WG publication message
10. get Advisor and/or MonAlisa to use request schema
11.	Agree on a base namespace
12.	Produce business logic document


* There was a lot of discussion on whether or not we should bother
reconciling the two current schemas if we are likely to throw them away when
the new schemas appear. Modifying the old schemas and working those changes
into the new schemas as the changes are made would result in:
+ an achievable current schema, which people can use in the interim
+ a more robust, useful and appropriate replacement, which we can tell
people is on the way
However, there was no clear consensus about whether or not this was a good
idea, and so it will be discussed during a phone call in a few weeks.

* Paul and Loukik should share their document-literal with the groupd. That
is, point people at the combined schemas and write some form of "How To"
guide. This may even result in someone developing a validation API.

* Dan and Martin are more than happy to press ahead with the new schema
work, but need good responses from the group whenever they make iterations.

* The next face-to-face meeting was also discussed. Korea (the next GGF)
will be a funding problem for some people. It was suggested that we should
aim for a face-to-face meeting tied in with another event, e.g. JointTechs
which would be more affordable. However, some form of attendance by NM-WG at
GGF13 will be important to gain buy in from Asia-Pac, especially if we have
a good product to demonstrate. The suggested date for the next face-to-face
is January 10th. This gives people a date to focus on producing work for,
but leaves us with a couple of months to prepare for Korea.