Minutes in progress. To be completed with Frank´s notes
QoS and Anytime Workshop, 29-30 September 2008, Innsbruck
Meeting minutes
Attendees:
Agenda:
- Terminology
- QoS (ppt Axel, Luka,...)
- Anytime (VUA, Barry, Mick)
- Sutttgart meeting (how to present the status of wp5, request feedback,...)
- Demo server
- Remote issues (Georgina)
Terminology
Goal: Align terminology with other WPs. An initial feedback was received from Hamish and Naso to the http://wiki.larkc.eu/LarkcProject/WP5/docs/platform/ApiDiscussion and referenced us to deliverable D2.1.1. RDF Graph – one set of triples Data set – multiple graphs (collection of named graphs) D = {UG, <N1,G1>,...,<Nk,Gk>} UG= default graph (unnamed) Ni= name of graph Gi= RDF graph Triple set – part of a dataset (subset of the data set) Terminology slot in Stuttgart meeting: write initial input in the wiki. During the Stutt meeting, we must mention that we are aligning terminology and ask all partners to do the same in their respective WPs.
QoS
QoS and SLAs (Axel ppt) – See QoSaspects.ppt We must distinguish different categories of qos aspects:
- Functional description: What the plugin can do
- Non-functional / QoS related
- ...
After this meeting we should come up with the minimum set of qos parameters / plugin (mandatory)
QoS mapping high level – low level parameters – See LarkcProject/WP5/docs/platform/QoS Mapping We need to identify a minimum set of transformations for V1.0. In this first version it must be something simple. For V2 we can have also composition of pipelines,... and more complex transformations. We agree to create our own LarKC ontology, based on some ideas of existing qos ontologies, but not reuse a general one. Maybe link the LarKC ontology afterwards to an existing general one.
QoS ontology for web services (Luka ppt) – See LarKC QOS LL.pptx The idea of grouping the parameters in different categories must be considered in LarKC (performance, reliability,...). This will be considered for the definition of the ontology/vocabulary on QoS parameters QoS parameters brainstorming to be done in the afternoon.
Anytime
Some thoughts from Frank. See (Input from Frank!!) Relationship between anytime and qos: Anytime == asynchronous Non-anytime == synchronous Anytime = gradual trade off between quality and resources Control parameter: when you cannot control the time, you find a substitute parameter to control the answer, e.g the size of the input. I increase the size of the input with every iteration in order to obtain a more precise answer every time. We would like to reuse the results of the previous iteration in the next one: Incremental. Sometimes it is not possible for some kind of components. Contract vs interruptible anytime behaviour
- Contract: give me the best answer you find in 5 sec
- Interruptible: you interrupt whenever you want to get an answer
Different types of performance profiles (see figures)
Mick: We have to distinguish between
- Anytime interface to LarKC
- Internal anytime behaviour
End user qos requirements: something to discuss in stuttg with the use cases wps. Different profiles for every parameter in the plugin Tomorrow talk more concretely about architecture and how to implement
QoS parameters brainstorming. See http://wiki.larkc.eu/LarkcProject/WP5/QoSAspects
Differentiate User constraints vs Plugin constraints Performance (and other qos) parameters for the different plugins. There are some wps working on this kind of parameters. We have some info already in D4.1, D5.5.1, D2.1.1, D9.2 (in progress). We should have a look at the existing material in order to align with them. Also we will need feedback from Use cases (on User constraints) and Plugins Wps (Plugin constraints) during Stutt meeting.
Cyc platform status (Luka) – Demo
Still have to remove some proprietary jar files. He will try to do it before Stutt meeting
Some architectural discussions
Agreed: LarKC will have a sparql interface towards the external world. The input to larkc will be a sparql query. Current prototype interfaces in Java. Does it have sense to keep them in java or implement them with other interface (implement a http interface?, should we consider already web services interface? Discussion on how to implement the streaming queues from and to the plugins. What happen if the entry queue is overloaded? How the data is communicated from plugin to plugin (pipes)? CurrentUIBK prototype is passing data always through the Decider, but this can be a bottleneck. We should implement a way to pass data directly from plugin to plugin. Not intelligent queues, it is the job of the consumer to decide what to do with the data streaming coming to it. Programming Models to consider: Streaming vs contract model Do we consider both models? Only streaming? Can we agree on a solution that allows us to implement both models with a same approach? Once the Decider plugs together the plugins, shall the reasoner ask directly the select that he needs more data? Or shall this question go through the decider?? Different models:
- Decider plugs the plugins, e.g I + S + R. Execute the complete pipeline and wait for the R answer. Then decides what to do the next. In the middle, the plugins talk to each other without passing through the D.
- Every plugin result goes through the Decider. Decider can decide which plugin to run next depending on the results from the previous one, consider certain aspects of the answer, such as qos parameters,... (the complete data answer is not analysed, but the qos...)
- Decider as an asynchronous monitoring component
In the 3 cases we must differentiate between control and data transfer interfaces Discussion on how to request next iteration of data (E.g from Select to Ident) we need to keep the state so that we can request “give me next set of data” we need to specify “give me loop 2” When we replace e.g the identifier, loop 3 for the resoner will be loop 1 for the new Identifier. Who shall keep this state and translate to the new one? The decider? This needs further discussion Agreed definitions: Data pipes: Streams of (iterated) current objects (e.g. stream of graphs) Control pipes: qos vocabulary + contract parameters (e.g. i tell you what i want next) The contract parameters may include info such as the pipe i want the data to come in Next improvements in the prototype: Current iteration: we implement qos and anytime behaviour in the current prototype Next iteration: we will consider remote issues, http interfaces, or web services,... Contract parameters: Postpone decision. First priority: Anytime Demo with first set of qos parameters
Stuttgart WP5 meeting
Monday afternoon plenary session (1/2 hour for wp5)
- LarKC API for non Java programmers Call to plugin wps (for feedback)
- Call to use cases wps (for feedback) (We need to tell them what we need from them and also terminology issues)
- Web demo: present first some slides on what is going on inside (config. of the pipeline,...) (scripted DECIDE) Cyc Platform demo (intelligent DECIDE) (Consider possibility to plug the real Cyc platform in the web demo)
AP Georgina: Send wpleaders info and request to prepare something for the session
AP Georgina: required people email
- WP2: Hamish, Naso, Jose, WICI WP3: daniele, Volker WP4: Zhisheng, Florian, Uwe WP6: Emanuele, Irene, Saltlux? WP7a: Vassil, Bo WP7b: Angus, Worldhealth?
Send them email by end of this week. Announcing this joint session and that they will get some material in advance to prepare the session.
AP Georgina: prepare first draft of ppt for the plenary. Iterations with Barry, Mick, Luka
Discussion with WP2, 3, 4: QoS-plugin; API for non java programmers
Discussion with WP6, 7: QoS-user; Mapping storyboards
AP: Prepare this material before the meeting. Agree on it during the next developers telco (next Tuesday)
Demo Server
AP: HLRS to make a PC available for running demos. Requirements: Tomcat. No special requirements on performance AP: Axel to chek about domain issues for the demo server
Remote issues
Discussion postponed (lower priority). Some thoughts already in the wiki (see LarkcProject/WP5/docs/platform/Remote Issues)
Other Pending issues
- Storage: where to store big amounts of data? How to access it?
- How to move from a Grid architecture (e.g. Marvin) to a P2P/Thinking@home architecture? Consider constraints such as low Bw, high latency,...