Dear All, during a discussion the question come up, what kinds of penalties are used within the various implementations of WS-Agreement SLAs. It would be very helpful to get some example use cases, example SLAs, and related information. Thank you, Philipp.
Hi Philipp, In AgentScape, we have experimented with penalties including: - simple notification (alerting the participants, but taking no other action) - canceling service, - canceling payment, - reducing payment (by a percentage specified in the SLA) but continuing service, and - charging a fixed fine per incident (a set amount specified in the SLA) but continuing service. We are also looking at the option of requesting renegotiation of the SLA, such as lower (more feasible) QoS for a lower payment. Another option we are looking at is integrating a reputation system that builds profiles of each participant in the system based on the number of successful or violated agreements. These are very interesting options, but we have not yet fully developed them. I've also attached some papers on these topics. Kind regards, Kassidy On 7 Sep 2010, at 12:25 , Philipp Wieder wrote:
Dear All,
during a discussion the question come up, what kinds of penalties are used within the various implementations of WS-Agreement SLAs. It would be very helpful to get some example use cases, example SLAs, and related information.
Thank you, Philipp. -- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- Kassidy Clark, MSc. Systems Engineering Section Faculty of Technology, Policy and Management Delft University of Technology
Hi Kassidy, thank you, this is very helpful. Maybe, in case we find more people interested in this topic, we can think about putting it on the next OGF's agenda. For me, I look into it for the SLA4D-Grid project. Best regards, Philipp. Am 07.09.10 13:21, schrieb Kassidy Clark:
Hi Philipp,
In AgentScape, we have experimented with penalties including: - simple notification (alerting the participants, but taking no other action) - canceling service, - canceling payment, - reducing payment (by a percentage specified in the SLA) but continuing service, and - charging a fixed fine per incident (a set amount specified in the SLA) but continuing service.
We are also looking at the option of requesting renegotiation of the SLA, such as lower (more feasible) QoS for a lower payment. Another option we are looking at is integrating a reputation system that builds profiles of each participant in the system based on the number of successful or violated agreements. These are very interesting options, but we have not yet fully developed them.
I've also attached some papers on these topics.
Kind regards, Kassidy
Dear Philipp, Thanks for initiating this thread. There was some interest in this area some time ago, I also asked the same question that you are asking in the context of the SORMA project. Did not get a lot of replies. In the work that Kassidy is identified -- we were primarily interested in a financial debit in case of non-conformance to pre-agreed SLA terms. However, I believe there could be a number of other options -- such as re-planning/re-scheduling or supporting capacity planning whereby the penalty is used as a means to support future resource provisioning. I guess two issues that were still not clear to me here were: (i) who does the penalty enforcement; (ii) who does the monitoring (i.e. some kind of "trusted" monitoring is assumed often). regards Omer On 07/09/2010 12:36, Philipp Wieder wrote:
Hi Kassidy,
thank you, this is very helpful.
Maybe, in case we find more people interested in this topic, we can think about putting it on the next OGF's agenda. For me, I look into it for the SLA4D-Grid project.
Best regards, Philipp.
Am 07.09.10 13:21, schrieb Kassidy Clark:
Hi Philipp,
In AgentScape, we have experimented with penalties including: - simple notification (alerting the participants, but taking no other action) - canceling service, - canceling payment, - reducing payment (by a percentage specified in the SLA) but continuing service, and - charging a fixed fine per incident (a set amount specified in the SLA) but continuing service.
We are also looking at the option of requesting renegotiation of the SLA, such as lower (more feasible) QoS for a lower payment. Another option we are looking at is integrating a reputation system that builds profiles of each participant in the system based on the number of successful or violated agreements. These are very interesting options, but we have not yet fully developed them.
I've also attached some papers on these topics.
Kind regards, Kassidy
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk
Hi, just a quick answer to (ii) Having now dealt with several approaches, I think we have to deal with two different kinds of monitoring. a) is the monitoring, which is done inside a Service Provider and which allows to monitor all kind of data (as needed) b) is a monitoring, which a Service Provider potentially offers to a Customer or to some sort of Monitoring Broker (which acts on behalf of the Customer, may be trusted). We assume, that the monitored data here will need to be "anonymized" or "filtered" to ensure the confidentiality of the SPs insides, but at the same time allow the Customer to see what happens. Generally this does of course not remove the potential of "faking" monitoring data to the outsider to give him/her the feeling that everything is fine. So thats a matter of trust. In all cases, the monitored values need to be evaluated somehow, which may lead to some sort of event driven logging and based on these logged occurances, penalties may be charged in a global accounting/billing process. Just my two cents Bastian Am 07.09.2010 14:52, schrieb Omer F. Rana:
Dear Philipp,
Thanks for initiating this thread. There was some interest in this area some time ago, I also asked the same question that you are asking in the context of the SORMA project. Did not get a lot of replies.
In the work that Kassidy is identified -- we were primarily interested in a financial debit in case of non-conformance to pre-agreed SLA terms. However, I believe there could be a number of other options -- such as re-planning/re-scheduling or supporting capacity planning whereby the penalty is used as a means to support future resource provisioning.
I guess two issues that were still not clear to me here were: (i) who does the penalty enforcement; (ii) who does the monitoring (i.e. some kind of "trusted" monitoring is assumed often).
regards Omer
On 07/09/2010 12:36, Philipp Wieder wrote:
Hi Kassidy,
thank you, this is very helpful.
Maybe, in case we find more people interested in this topic, we can think about putting it on the next OGF's agenda. For me, I look into it for the SLA4D-Grid project.
Best regards, Philipp.
Am 07.09.10 13:21, schrieb Kassidy Clark:
Hi Philipp,
In AgentScape, we have experimented with penalties including: - simple notification (alerting the participants, but taking no other action) - canceling service, - canceling payment, - reducing payment (by a percentage specified in the SLA) but continuing service, and - charging a fixed fine per incident (a set amount specified in the SLA) but continuing service.
We are also looking at the option of requesting renegotiation of the SLA, such as lower (more feasible) QoS for a lower payment. Another option we are looking at is integrating a reputation system that builds profiles of each participant in the system based on the number of successful or violated agreements. These are very interesting options, but we have not yet fully developed them.
I've also attached some papers on these topics.
Kind regards, Kassidy
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- ------------------------------------------------------------------- Bastian Koller Head of the Service Management& Business Processes (SANE) Group Höchstleistungsrechenzentrum Universität Stuttgart Allmandring 30 70550 Stuttgart Phone: ++49 (0)711-685-65891 Mobile: ++49 (0)173-7028701 Fax: ++49 (0)711-685-65832 `. ___ __,' __`. _..----....____ __...--.'``;. ,. ;``--..__ .' ,-._ _.-' _..-''-------' `' `' `' O ``-''._ (,;') _,' ,'________________ \`-._`-',' `._ ```````````------...___ '-.._'-: ```--.._ ,. ````--...__\-. `.--. `-` ____ | |` `. `. ,'`````. ; ;` `._`. __________ `. \'__/` `-:._____/______/___/____`. \ ` | `._ `. \ `._________`-. `. `.___ `------'`
Dear Omer, thanks for adding information to Kassidy's answer. I will collect the issues and questions on the GRAAP Wiki and I think it might be a good idea to put it on the agenda at the next OGF. We at SLA4D-Grid are especially interested in the second issue you raised, not soley in trusting monitoring data, but also regarding technical issues like metrics etc. Best regards, Philipp. Am 07.09.10 14:52, schrieb Omer F. Rana:
Dear Philipp,
Thanks for initiating this thread. There was some interest in this area some time ago, I also asked the same question that you are asking in the context of the SORMA project. Did not get a lot of replies.
In the work that Kassidy is identified -- we were primarily interested in a financial debit in case of non-conformance to pre-agreed SLA terms. However, I believe there could be a number of other options -- such as re-planning/re-scheduling or supporting capacity planning whereby the penalty is used as a means to support future resource provisioning.
I guess two issues that were still not clear to me here were: (i) who does the penalty enforcement; (ii) who does the monitoring (i.e. some kind of "trusted" monitoring is assumed often).
regards Omer
On 07/09/2010 12:36, Philipp Wieder wrote:
Hi Kassidy,
thank you, this is very helpful.
Maybe, in case we find more people interested in this topic, we can think about putting it on the next OGF's agenda. For me, I look into it for the SLA4D-Grid project.
Best regards, Philipp.
Am 07.09.10 13:21, schrieb Kassidy Clark:
Hi Philipp,
In AgentScape, we have experimented with penalties including: - simple notification (alerting the participants, but taking no other action) - canceling service, - canceling payment, - reducing payment (by a percentage specified in the SLA) but continuing service, and - charging a fixed fine per incident (a set amount specified in the SLA) but continuing service.
We are also looking at the option of requesting renegotiation of the SLA, such as lower (more feasible) QoS for a lower payment. Another option we are looking at is integrating a reputation system that builds profiles of each participant in the system based on the number of successful or violated agreements. These are very interesting options, but we have not yet fully developed them.
I've also attached some papers on these topics.
Kind regards, Kassidy
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
Hi.
during a discussion the question come up, what kinds of penalties are used within the various implementations of WS-Agreement SLAs. It would be very helpful to get some example use cases, example SLAs, and related information.
In AssessGrid we assumed a simple monetary penalty. One interesting usecase we investigated was supporting a time dependent penalty definition that allows revoking a signed SLA for a specific cost. E.g.: - cancel the SLA within the first 5 minutes because you needed a commitment by a provider but found a better one later. - cancel an SLA 24h before some job is actually scheduled because you have reserved resources a long time in advance and realize that you will not use them. Best regards, Dominic
participants (5)
-
Bastian Koller -
Dominic Battre -
Kassidy Clark -
Omer F. Rana -
Philipp Wieder