[nm-wg] postpone today's call?? & current schemas outstanding issues

["Leese, MJ (Mark)" <m.j.leese@dl.ac.uk>]

Hi folks,

We're due to have a conference call today at 11am ET, 4pm GMT etc. (i.e. the
usual time :) I'm more than happy for his to take place, but I won't be able
to chair the call as I'm ill at home in bed :-(

I assume that the dial-in info is the same as usual, and the agenda would
be:

+ follow-up questions on the new schemas from Martin and Dan
+ further discussion of the major topics raised during the last week or so,
i.e. stabilising the current schemas, and inclusion of transaction IDs
+ discussion of outstanding issues to allow stabilisation of the current
schemas by Christmas

Perhaps people can dial in, see who else does the same, and what can be
discussed. ALTERNATIVELY, we can postpone until next Tuesday (November 9th)
when I will NOT be feeling this bad ;-) I throw that decision open to the
floor.



Also, work is progressing on stabilising the current schemas by Christmas.
Paul and I spent a day last week looking at the request schema. The
outstanding issues are/were....

>From the request schema requirements doc:

* (point 4 in requirements) Discussion is required on whether it should be
possible to specify source parameters using parameter specific tags, and
destination parameters using a command-line style parameter list, and
vice-versa.

What we're actually saying is that you could request a test, specifying the
destination machine's parameters using parameter specific tags (e.g. <port
endpoint="dest">5001</port>) and on your own machine (the source end) with a
parameter list (e.g. "-p 5001 -w 1048K" for iperf).

But we decided that this was not a good idea, as there's too big a scope for
contention. Sticking with the above example, specifying the source end
parameters with a list ("-p 5001 -w 1048") you'd then have to reject any
parameter specific tags that weren't specific to the opposite end (as they
could be contentious).

Unfortunately, it's not possible to enforce this in the schema...

+ the command line style stuff is currently under the <tool> element. This
is perfectly logical, because if you don't specify a specific tool like
iperf, then the command line stuff makes no sense.
+ We could move the command line style stuff into the same secion that the
parameter specific tags appear in, and make it one OR the other, but that
separates the command line style stuff from the <tool> element which makes
no sense.

...so we leave things as they are, but Paul will comment the schema
appropriately.


* (point 6 in requirements) Discuss the inclusion of a field for transaction
IDs in both the request and existing publication schemas, to allow better
tracking of interactions.

Paul and I had a fairly long chat about this, and we're not sure it should
be in the schema itself. The arguments being that transaction IDs are fairly
generic things, and should perhaps be dealt with outside the NMWG specific
schema.

Paul thinks we can modify the WSDL describing NM-WG web services to to allow
objects other than <NetworkMeasurementRequest> to go in the SOAP body of
messages sent to those services. This would allow us tot put
<transactionInfo> or whatever into the SOAP messages, and not the schemas. 

So, we could define two or three different SOAP bodies...
1. request only
2. request + transaction info
3. transaction info only <-- interpreted as "send me the next batch"

...and people would pick which to send based on what they want to do.
Another advantage of this method is that it would advertise in a service's
WSDL whether or not the service was able to handle transaction IDs.



>From Warren's Brussels GGF presentation:

* Q: What is networkMeasurementRequest.request.subject.node.address.port
used for? An address makes sense, but not making it specific to a port?
A: This has been removed. We used it because it was in the report schema,
but we think it makes more sense for port to be a parameter in the request
schema, e.g. <port>5001</port>.


* Q: Why are we using
networkMeasurementRequest.request.subject.path.source|destination.version
when you cannot have source=IPv4 and destination=IPv6?

A: Jeff said in Brussels that there are valid situations in which you'd have
IPv4 at one end of a path, and IPv6 at the other. We want to look at using
"address families" instead. <-- creates new Outstanding Issue, although this
could probably be dealt with in the new schemas.


* Q: For networkMeasurementRequest.request.methodology.endpoint, what does
"endpoint=none" mean?

A: It was supposed to mean that the element applied to both endpoints
(source and dest) but we can see that it could be confusing. We now have
endpoint=source|dest and nothing else. If nothing is specfied, then the
receiving system assumes the element applies to both ends.


* Q:
networkMeasurementRequest.request.methodology.parameterSet.includesDisk? How
do you request that a test includes the disk?

A: We think what Warren was asking here was "What do you need
networkMeasurementRequest....includesDisk for? Isn't memory to memory or
disc to disc selected by the tool that you use?" In response to what we
think the question is..... networkMeasurementRequest....includesDisk exists
to let requestors control whether a test is memory-to-memory or
disc-to-disc. They may not want to select a specific tool, just a
disc-to-disc value for achievableBandwidth. Also, we think some tools can do
both. I forget the specific examples, but it was something like redirecting
output to /dev/null to ensure that the disk is used at the receive end. 

Warren: Please let us know if we've misunderstood what you were asking!



>From elsewhere:

* We decided recently to make parameter specific tags specific to one end of
a test path (source or destination) using an attribute, e.g.
<tool>iperf</tool><port endpoint="source">5001</port>. So why do we have the
parameter lists as <srcParameterList> and <destParameterList>. For
consistency shouldn't they be changed to <parameterList endpoint="">?

We think so, so Paul has changed the schema to include one <commandLine> tag
which can be made specific to either end of a test path.


* While we'll want to allow some parameters to be different at source and
destination ends of a test path (e.g. <port>) it won't make sense for all
parameters. I don't know if "protocol" will a parameter we decide to
include, be if so, this would make no sense....

	<protocol endpoint="source">TCP</protocol>
	<protocol endpoint="dest">UDP</protocol>

We could just allow all parameter tags to be source|destination specific,
but it means that receiving systems would have toc check for all stupid
cases, e.g. source=TCP, destination=UDP. So, do we want two groups of
parameters: one for those that can differ, and one for those that can't? 

Paul has changed the parameter tags we already have so that they can all be
made source|destination specific. He doesn't think it makes a great deal of
sense to do otherwise, e.g. you could say having source=IPv4 and
destination=IPv6 is wrong, but you'd be wrong! It would also make the schema
messy.



**** COMMENTS ARE ALWAYS WELCOME ****

Next we'll be trying to catch up with Dan's work on harmonising the two
schemas.



Cheers,

Mark.