From t-nakata at cw.jp.nec.com Wed Aug 22 03:41:29 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 22 Aug 2007 17:41:29 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46B005B6.4010203@hp.com> References: <46B005B6.4010203@hp.com> Message-ID: <002201c7e498$3bfa74a0$b084380a@Sakurai> Hi: I've put up some more things to ponder on the re-negotiation Wiki Page https://forge.gridforum.org/sf/wiki/do/viewPage/projects.graap-wg/wiki/ReNeg otiationWishlists?_message=1187773027531 esp. No.7 is rather a tough one. Comments welcome. Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070822/67f915c9/attachment.bin From mailinglists at battre.de Wed Aug 22 15:18:01 2007 From: mailinglists at battre.de (Dominic Battre) Date: Wed, 22 Aug 2007 22:18:01 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <002201c7e498$3bfa74a0$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> Message-ID: <46CC99F9.5030709@battre.de> Hi Toshi, I did some brainstorming and added some random comments/wishes/ideas. Please have a look whether anything could be useful for the further proceeding. I don't know how much you have discussed and discarded before. Please feel free to ask me, in case my comments are confusing. Best regards, Dominic Toshiyuki Nakata wrote: > Hi: > I've put up some more things to ponder on the re-negotiation Wiki Page > https://forge.gridforum.org/sf/wiki/do/viewPage/projects.graap-wg/wiki/ReNeg > otiationWishlists?_message=1187773027531 > esp. No.7 is rather a tough one. > > Comments welcome. > > Best Regards > Toshi > ----- > Toshiyuki Nakata ?????? > Executive Chief Engineer, Central Research Lab. NEC > 1753, Shimonumabe, Nakahara-Ku, > Kawasaki,Kanagawa 211-8666,Japan > Tel +81-44-431-7653 (NEC Internal 22-60035) > Fax +81-44-431-7609 (NEC Internal 22-60509) > > > > ------------------------------------------------------------------------ > > -- > graap-wg mailing list > graap-wg at ogf.org > http://www.ogf.org/mailman/listinfo/graap-wg From mailinglists at battre.de Wed Aug 22 17:05:05 2007 From: mailinglists at battre.de (Dominic Battre) Date: Thu, 23 Aug 2007 00:05:05 +0200 Subject: [GRAAP-WG] XPath issues in Creation Constraints Message-ID: <46CCB311.9010202@battre.de> Hi. As we are looking for interoperability tests and implementations start showing up, I have a question about common practice in the evaluation of creation constraints. I have raised the issue before, but I think I have never received an answer. The issue is: A creation constraint might have an xpath "//wsag:foobar" but it is very difficult to get the namespace that is bound to the "wsag:" prefix. At least in case Axis 1 that is used. Does Axis 2 solve this problem or any other toolkit? Otherwise the question is whether it is technically feasible to evaluate XPath expressions like that at all. If it is not feasible, it might be considered a problem in the WS-Agreement spec. The reason for my writing this is that I found this bug report: http://bugzilla.globus.org/globus/show_bug.cgi?id=4227 The Globus Toolkit community faced the same issue and surrendered - or lets say, they came up with a very nice solution: Introducing a sane query language TargetedXPath. This is the Schema: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/schema/core/query/ This is the Implementation: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/java/core/source/src/org/globus/wsrf/query/targetedXPath/ I like this approach a lot. Would this be a viable approach for WS-Agreement? Best regards, Dominic From t-nakata at cw.jp.nec.com Wed Aug 22 19:30:50 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 23 Aug 2007 09:30:50 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46CC99F9.5030709@battre.de> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> Message-ID: <006101c7e51c$db95a190$b084380a@Sakurai> Hi: Dominic? Thank you very much for your thoughtful comments. I'll just address the first one. For the rest, please give me some time. >ad "New EPR or re-write the current WS-AG document?" >during the renegotiation the agreement is in some kind of intermediate change (i.e. it might be in a proposed > new status that is not yet accepted by the other party), don't we need a new EPR for that? The reason that I wanted to re-write the current WS-AG rather than a new EPR was that one could never know who might be using the old EPR. In a complex scenario like the one I mentioned in Business Grid Computing case or some broker case, old EPR might be propagated to other parties who would be using it. So I thought that it would not be realistic to assure that the NEW EPR would be propagated to all the bodies who might be referring to the old EPR. On the other hand, re-writing the current WS-AG document kept by the Agreement Responder does cause a serious race condition when the AR is the requestor for modifying the Agreement. (ie. it must be re-written only after the AI says he agrees, but when?) >What would the ResourceProperties (e.g. the SDTs or GTs) look like in the intermediate state? (DB, 2007/08/22) I am assuming that the service (under the old SLA) is still being provided even while the renegotiation is going on. (If the service is stopped, then we don't need renegotiation. We just terminate the old agreement and create a new agreement) As for the rest of your comments, essentially I agree with you. The only problemis that some of them seem to be very difficult to address :-( In any case, please give me some time as I can only do this work sporadically. Best regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Dominic Battre [mailto:mailinglists at battre.de] > Sent: Thursday, August 23, 2007 5:18 AM > To: Toshiyuki Nakata > Cc: 'GRAAP-WG' > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiating an established Agreement > > Hi Toshi, > > I did some brainstorming and added some random comments/wishes/ideas. > Please have a look whether anything could be useful for the further > proceeding. I don't know how much you have discussed and discarded > before. Please feel free to ask me, in case my comments are confusing. > > Best regards, > > Dominic > > Toshiyuki Nakata wrote: > > Hi: > > I've put up some more things to ponder on the > re-negotiation Wiki Page > > > https://forge.gridforum.org/sf/wiki/do/viewPage/projects.graap > -wg/wiki/ReNeg > > otiationWishlists?_message=1187773027531 > > esp. No.7 is rather a tough one. > > > > Comments welcome. > > > > Best Regards > > Toshi > > ----- > > Toshiyuki Nakata ?????? > > Executive Chief Engineer, Central Research Lab. NEC > > 1753, Shimonumabe, Nakahara-Ku, > > Kawasaki,Kanagawa 211-8666,Japan > > Tel +81-44-431-7653 (NEC Internal 22-60035) > > Fax +81-44-431-7609 (NEC Internal 22-60509) > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > -- > > graap-wg mailing list > > graap-wg at ogf.org > > http://www.ogf.org/mailman/listinfo/graap-wg > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070823/799875b4/attachment.bin From mailinglists at battre.de Thu Aug 23 03:24:56 2007 From: mailinglists at battre.de (Dominic Battre) Date: Thu, 23 Aug 2007 10:24:56 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <006101c7e51c$db95a190$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> Message-ID: <46CD4458.3050101@battre.de> Hi Toshi, (I am resending this mail because I used the wrong email address and it bounced) > Hi: Dominic? > Thank you very much for your thoughtful comments. > I'll just address the first one. For the rest, please give me some > time. > >> ad "New EPR or re-write the current WS-AG document?" >> during the renegotiation the agreement is in some kind of >> intermediate change (i.e. it might be in a proposed >> new status that is not yet accepted by the other party), don't we >> need a new EPR for that? > > The reason that I wanted to re-write the current WS-AG rather than a > new EPR was that one could never know > who might be using the old EPR. In a complex scenario like the one I > mentioned in Business Grid Computing case or > some broker case, old EPR might be propagated to other parties who > would be using it. For that reason I mentioned the "superseded by" information that could be added to the context. A third party might need to check whether the SLA is superseded by another SLA periodically. Kind of ugly... > So I thought that it would not be realistic to assure that the NEW EPR > would be propagated to all the > bodies who might be referring to the old EPR. > > On the other hand, re-writing the current WS-AG document kept by the > Agreement Responder does cause > a serious race condition when the AR is the requestor for modifying > the Agreement. > (ie. it must be re-written only after the AI says he agrees, but > when?) oh, does this imply that you want a simple two way communication? AI ------ 1. please change SLA like this ------> AR 2. AR changes SLA <------ 3. confirms change ------------------ or AI ------ 1. please change SLA like this ------> AR 2. AR rejects change <------------- 3. exception ------------------ I am not sure whether this is sufficient. Suppose that the SLA carries a price tag that needs to be calculated by the AR. I would like to see some kind of two phase protocol... AI ------ 1. please change SLA like this ------> AR 2. AR decides that it can change SLA 3. AR calculates price of modification <----------- 4. new offer ------------------ 5. AI decides whether change is worth the price --------- 6. confirmation/rejection ---------> In my opinion, for negotiation and for renegotiation we need this kind of request-offer-commit protocol. So it is no easier if the AR initiates the renegotiation than if the AI initiates the renegotiation. But I think that we see the same issue there: "What do the resource properties of the agreement look like if an offer has been sent but not confirmed?" I agree that creating a new agreement EPR is not very beautiful. Maybe one could create such an EPR for negotiation until a party commits. At that time Context, SDTs and GTs are copied to the old agreement. Best regards, Dominic From Oliver.Waeldrich at scai.fraunhofer.de Thu Aug 23 04:45:47 2007 From: Oliver.Waeldrich at scai.fraunhofer.de (=?iso-8859-1?Q?Oliver_W=E4ldrich?=) Date: Thu, 23 Aug 2007 11:45:47 +0200 Subject: [GRAAP-WG] XPath issues in Creation Constraints In-Reply-To: <46CCB311.9010202@battre.de> Message-ID: <001801c7e56a$64b201b0$51851a81@gelbwurz> Hi Dominic, In the XMLBeans implementation you can declare the namespace prefix directly in the Xpath call. The Xpath expression we use are therefore constructed as follows: declare namespace foo='http://bar.org'; $this/foo:bar I did not find the place in the Xpath specification where the namespace declaration is defined, but http://www.w3.org/TR/xquery-xpath-parsing/ indicates that this should be standard conform. However, this expressions work for XMLBeans. I think other implementations should support this as well (Saxon?). Best regards, Oliver -----Urspr?ngliche Nachricht----- Von: graap-wg-bounces at ogf.org [mailto:graap-wg-bounces at ogf.org] Im Auftrag von Dominic Battre Gesendet: Donnerstag, 23. August 2007 00:05 An: GRAAP-WG Betreff: [GRAAP-WG] XPath issues in Creation Constraints Hi. As we are looking for interoperability tests and implementations start showing up, I have a question about common practice in the evaluation of creation constraints. I have raised the issue before, but I think I have never received an answer. The issue is: A creation constraint might have an xpath "//wsag:foobar" but it is very difficult to get the namespace that is bound to the "wsag:" prefix. At least in case Axis 1 that is used. Does Axis 2 solve this problem or any other toolkit? Otherwise the question is whether it is technically feasible to evaluate XPath expressions like that at all. If it is not feasible, it might be considered a problem in the WS-Agreement spec. The reason for my writing this is that I found this bug report: http://bugzilla.globus.org/globus/show_bug.cgi?id=4227 The Globus Toolkit community faced the same issue and surrendered - or lets say, they came up with a very nice solution: Introducing a sane query language TargetedXPath. This is the Schema: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/schema/core/query/ This is the Implementation: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/java/core/source/src/org /globus/wsrf/query/targetedXPath/ I like this approach a lot. Would this be a viable approach for WS-Agreement? Best regards, Dominic -- graap-wg mailing list graap-wg at ogf.org http://www.ogf.org/mailman/listinfo/graap-wg From mailinglists at battre.de Thu Aug 23 06:46:53 2007 From: mailinglists at battre.de (Dominic Battre) Date: Thu, 23 Aug 2007 13:46:53 +0200 Subject: [GRAAP-WG] XPath issues in Creation Constraints In-Reply-To: <001801c7e56a$64b201b0$51851a81@gelbwurz> References: <001801c7e56a$64b201b0$51851a81@gelbwurz> Message-ID: <46CD73AD.9060807@battre.de> Hi Oliver, I think I was not clear enough. This is part of my SLA template: //wsag:GuaranteeTerm[@wsag:Name='StageIn']/\ wsag:ServiceLevelObjective/wsag:CustomServiceLevel/\ assessgrid:ProvideStageInFilesBy I can do something like Location_Type location = ...; // get it from the java object String xpath = location.getValue(); The problem is that xpath contains "wsag:" and "assessgrid:" which need to be bound to the correct namespace and looked up in order to generate your xquery expression: declare namespace wsag='what do I put here?' Axis 1.x does not allow me to get all namespace bindings of the DOM node that is represented by "location". Chapter 4.2.5.1, 5.1.1 and Appendix 2 of the WS-Agreement spec use XPath expressions instead of XQuery expressions as suggested by you. So the problem is: XPath expressions as in Appendix 2 may be impossible to evaluate with current toolkits (I may be wrong, but the Globus Toolkit faced the same problem). Alternatives would be to use XQuery as you indicated or the TargetedXPath query that is used in the Globus Toolkit. I think it would be a good idea to reflect such a proposal in the WS-Agreement spec. In either way, I think that it would be necessary to specify the query dialect used, which in my opinion is not possible at the moment. This is common practice e.g. in WSRF: http://docs.oasis-open.org/wsrf/wsrf-ws_resource_properties-1.2-spec-os.pdf -> Section 5.4 (page 19) Other parts of WS-Agreement have the same issue, that no dialect is specified. Best regards, Dominic Oliver W?ldrich wrote: > Hi Dominic, > > In the XMLBeans implementation you can declare the namespace prefix directly > in the Xpath call. The Xpath expression we use are therefore constructed as > follows: > > declare namespace foo='http://bar.org'; $this/foo:bar > > I did not find the place in the Xpath specification where the namespace > declaration is defined, but > > http://www.w3.org/TR/xquery-xpath-parsing/ > > indicates that this should be standard conform. However, this expressions > work for XMLBeans. I think other implementations should support this as well > (Saxon?). > > Best regards, > Oliver > > -----Urspr?ngliche Nachricht----- > Von: graap-wg-bounces at ogf.org [mailto:graap-wg-bounces at ogf.org] Im Auftrag > von Dominic Battre > Gesendet: Donnerstag, 23. August 2007 00:05 > An: GRAAP-WG > Betreff: [GRAAP-WG] XPath issues in Creation Constraints > > > Hi. > > As we are looking for interoperability tests and implementations start > showing up, I have a question about common practice in the evaluation of > creation constraints. > > I have raised the issue before, but I think I have never received an answer. > > The issue is: > > A creation constraint might have an xpath "//wsag:foobar" but it is very > difficult to get the namespace that is bound to the "wsag:" prefix. At least > in case Axis 1 that is used. > > Does Axis 2 solve this problem or any other toolkit? Otherwise the question > is whether it is technically feasible to evaluate XPath expressions like > that at all. If it is not feasible, it might be considered a problem in the > WS-Agreement spec. > > The reason for my writing this is that I found this bug report: > http://bugzilla.globus.org/globus/show_bug.cgi?id=4227 > > The Globus Toolkit community faced the same issue and surrendered - or lets > say, they came up with a very nice solution: Introducing a sane query > language TargetedXPath. > > This is the Schema: > http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/schema/core/query/ > > This is the Implementation: > http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/java/core/source/src/org > /globus/wsrf/query/targetedXPath/ > > I like this approach a lot. Would this be a viable approach for > WS-Agreement? > > Best regards, > > Dominic > -- > graap-wg mailing list > graap-wg at ogf.org > http://www.ogf.org/mailman/listinfo/graap-wg > > From t-nakata at cw.jp.nec.com Thu Aug 23 07:30:21 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 23 Aug 2007 21:30:21 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46CD4458.3050101@battre.de> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> Message-ID: <003401c7e581$5f221700$b084380a@Sakurai> HI Dominic: Thanx for the response. > For that reason I mentioned the "superseded by" information that could > be added to the context. A third party might need to check whether the > SLA is superseded by another SLA periodically. Kind of ugly... I see. I had been wondering what you meant by "superseded by".. It might be necessary to have a Notification sent to all the bodies using the old EPR... > > oh, does this imply that you want a simple two way communication? > > AI ------ 1. please change SLA like this ------> AR > 2. AR changes SLA > <------ 3. confirms change ------------------ > > or > > AI ------ 1. please change SLA like this ------> AR > 2. AR rejects change > <------------- 3. exception ------------------ > for AI to AR yes, for AR to AI this becomes a bit more complex.. (Please cf. the ppt attached in the Wiki page) > > AI ------ 1. please change SLA like this ------> AR > 2. AR decides that it can change SLA > 3. AR calculates price of modification > <----------- 4. new offer ------------------ > 5. AI decides whether change is worth the price > --------- 6. confirmation/rejection ---------> > I agree that this is more beautiful. OTOH I think that this raises the issue related to two phase commit protocol that had been discussed for a long time and in a heated manner by quite a number of people (before my time actually) and finally got rejected in the original WS-Agreement protocol. I am a bit afraid of waking the sleeping monster, but I welcome people's comments.. Best regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Dominic Battre [mailto:mailinglists at battre.de] > Sent: Thursday, August 23, 2007 5:25 PM > To: Toshiyuki Nakata > Cc: 'GRAAP-WG' > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiating an established Agreement > > Hi Toshi, > > (I am resending this mail because I used the wrong email > address and it > bounced) > > > Hi: Dominic? > > Thank you very much for your thoughtful comments. > > I'll just address the first one. For the rest, please give me some > > time. > > > >> ad "New EPR or re-write the current WS-AG document?" > >> during the renegotiation the agreement is in some kind of > >> intermediate change (i.e. it might be in a proposed > >> new status that is not yet accepted by the other party), don't we > >> need a new EPR for that? > > > > The reason that I wanted to re-write the current WS-AG rather than a > > new EPR was that one could never know > > who might be using the old EPR. In a complex scenario like the one I > > mentioned in Business Grid Computing case or > > some broker case, old EPR might be propagated to other parties who > > would be using it. > > For that reason I mentioned the "superseded by" information that could > be added to the context. A third party might need to check whether the > SLA is superseded by another SLA periodically. Kind of ugly... > > > So I thought that it would not be realistic to assure that > the NEW EPR > > would be propagated to all the > > bodies who might be referring to the old EPR. > > > > On the other hand, re-writing the current WS-AG document kept by the > > Agreement Responder does cause > > a serious race condition when the AR is the requestor for modifying > > the Agreement. > > (ie. it must be re-written only after the AI says he agrees, but > > when?) > > oh, does this imply that you want a simple two way communication? > > AI ------ 1. please change SLA like this ------> AR > 2. AR changes SLA > <------ 3. confirms change ------------------ > > or > > AI ------ 1. please change SLA like this ------> AR > 2. AR rejects change > <------------- 3. exception ------------------ > > > I am not sure whether this is sufficient. Suppose that the > SLA carries a > price tag that needs to be calculated by the AR. I would like to see > some kind of two phase protocol... > > AI ------ 1. please change SLA like this ------> AR > 2. AR decides that it can change SLA > 3. AR calculates price of modification > <----------- 4. new offer ------------------ > 5. AI decides whether change is worth the price > --------- 6. confirmation/rejection ---------> > > > In my opinion, for negotiation and for renegotiation we need this kind > of request-offer-commit protocol. So it is no easier if the > AR initiates > the renegotiation than if the AI initiates the renegotiation. But I > think that we see the same issue there: "What do the resource > properties > of the agreement look like if an offer has been sent but not > confirmed?" > > I agree that creating a new agreement EPR is not very beautiful. Maybe > one could create such an EPR for negotiation until a party commits. At > that time Context, SDTs and GTs are copied to the old agreement. > > Best regards, > > Dominic > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070823/ebcfa662/attachment.bin From mailinglists at battre.de Thu Aug 23 08:08:30 2007 From: mailinglists at battre.de (Dominic Battre) Date: Thu, 23 Aug 2007 15:08:30 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <003401c7e581$5f221700$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> Message-ID: <46CD86CE.103@battre.de> Hi Toshi, >> For that reason I mentioned the "superseded by" information that could >> be added to the context. A third party might need to check whether the >> SLA is superseded by another SLA periodically. Kind of ugly... > > I see. I had been wondering what you meant by "superseded by".. > It might be necessary to have a Notification sent to all the bodies using > the old EPR... Either that or to forward all requests transparently in the Agreement webservice. (i.e. if a message is sent to the old agreement it is automatically forwarded and answered to/by the new agreement). In case of the notification, we have again the problem that the delay of delivering the notification means that some parties are unaware of the new state for some time. >> AI ------ 1. please change SLA like this ------> AR >> 2. AR decides that it can change SLA >> 3. AR calculates price of modification >> <----------- 4. new offer ------------------ >> 5. AI decides whether change is worth the price >> --------- 6. confirmation/rejection ---------> >> > > I agree that this is more beautiful. > OTOH I think that this raises the issue related to two phase commit protocol > that had been discussed > for a long time and in a heated manner by quite a number of people (before > my time actually) > and finally got rejected in the original WS-Agreement protocol. > > I am a bit afraid of waking the sleeping monster, but I welcome people's > comments.. Yes, I remember the discussion in Leeds. But on the other hand: "A WS-AGREEMENT BASED RESOURCE NEGOTIATION FRAMEWORK FOR MOBILE AGENTS" by D.G.A. Mobach, B.J. Overeinder, and F.M.T. Brazier introduced the additional commit and argues why it is important. Oliver's WSAG4J has a commit message in the NegotiationAgreement interface (I don't know whether it is required or whether it is implemented for some historic reasons). Our Negotiation Manager implementation (online since a few days ago: https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki) needs it. So, yes, there are problems but it looks like a lot of people want to have this extra commit message. Are there any written records on the pros and cons of having the 2PC? Best regards, Dominic From t-nakata at cw.jp.nec.com Thu Aug 23 08:30:31 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 23 Aug 2007 22:30:31 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46CD86CE.103@battre.de> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> Message-ID: <000801c7e589$c704f6a0$b084380a@Sakurai> Hi Dominic: > So, yes, there are problems but it looks like a lot of people want to > have this extra commit message. Are there any written records on the > pros and cons of having the 2PC? I think this info. is very important. Unfortunately, I am not able to address this issue. Karl or others, please respond.. Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Dominic Battre [mailto:mailinglists at battre.de] > Sent: Thursday, August 23, 2007 10:09 PM > To: Toshiyuki Nakata > Cc: 'GRAAP-WG' > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiating an established Agreement > > Hi Toshi, > > >> For that reason I mentioned the "superseded by" > information that could > >> be added to the context. A third party might need to check > whether the > >> SLA is superseded by another SLA periodically. Kind of ugly... > > > > I see. I had been wondering what you meant by "superseded by".. > > It might be necessary to have a Notification sent to all > the bodies using > > the old EPR... > > Either that or to forward all requests transparently in the Agreement > webservice. (i.e. if a message is sent to the old agreement it is > automatically forwarded and answered to/by the new agreement). > > In case of the notification, we have again the problem that > the delay of > delivering the notification means that some parties are unaware of the > new state for some time. > > > >> AI ------ 1. please change SLA like this ------> AR > >> 2. AR decides that it can > change SLA > >> 3. AR calculates price of > modification > >> <----------- 4. new offer ------------------ > >> 5. AI decides whether change is worth the price > >> --------- 6. confirmation/rejection ---------> > >> > > > > I agree that this is more beautiful. > > OTOH I think that this raises the issue related to two > phase commit protocol > > that had been discussed > > for a long time and in a heated manner by quite a number of > people (before > > my time actually) > > and finally got rejected in the original WS-Agreement protocol. > > > > I am a bit afraid of waking the sleeping monster, but I > welcome people's > > comments.. > > Yes, I remember the discussion in Leeds. But on the other hand: > > "A WS-AGREEMENT BASED RESOURCE NEGOTIATION FRAMEWORK FOR > MOBILE AGENTS" > by D.G.A. Mobach, B.J. Overeinder, and F.M.T. Brazier introduced the > additional commit and argues why it is important. > > Oliver's WSAG4J has a commit message in the NegotiationAgreement > interface (I don't know whether it is required or whether it is > implemented for some historic reasons). > > Our Negotiation Manager implementation (online since a few days ago: > https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki) needs it. > > So, yes, there are problems but it looks like a lot of people want to > have this extra commit message. Are there any written records on the > pros and cons of having the 2PC? > > Best regards, > > Dominic > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070823/4354c5df/attachment.bin From parkinm at cs.man.ac.uk Fri Aug 24 03:35:50 2007 From: parkinm at cs.man.ac.uk (Michael Parkin) Date: Fri, 24 Aug 2007 10:35:50 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <000801c7e589$c704f6a0$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> Message-ID: Toshi, Dominic, As no-one else has replied... On 23 Aug 2007, at 15:30, Toshiyuki Nakata wrote: >> So, yes, there are problems but it looks like a lot of people want to >> have this extra commit message. Are there any written records on the >> pros and cons of having the 2PC? > > I think this info. is very important. A 2PC-type protocol works well when you control everything. However, where autonomous services are involved in (possibly) different administrative domains (such as in a business environment) the cons of using the 2PC style in agreements like this are well understood, for example: * Skeen's paper [1] on commit protocols describes why 2PC is a blocking protocol. * Pat Helland (formally Amazon, now Microsoft) describes the 2PC protocol as the "anti-availability protocol" [2] because of the fact it can block the transaction manager (Dominic, this would be the AR in your protocol). As he says: "[2pc] is best used sparingly". (Toshi - I also direct you to his article on "accountants don't use erasers" [3] about why agreements should not be overwritten). * Mark McKeown also has a blog article [4] about the difficulty of distributed consensus, which is essentially what you're trying to achieve (FTA: "consensus was originally called agreement"). * If you want a lighter read the Wikipedia article [5] also discusses 2PC's blocking. About the Mobach, et. al. paper [6] - the last three steps in Figure 2.4 are a 2PC-type protocol. When the 'DC' (from the paper) returns the 'agreement offer' to 'A' they are blocked from offering those resources to anyone else (although this is an assumption because the paper doesn't say explicitly what the 'agreement offer' actually means). Imagine the scenario: DC returns an offer to A1 saying 'these resources for ?10". Meanwhile A2, who is prepared to pay ?10,000 for the same resources cannot make the agreement because DC has offered them to A1. A2 then goes and makes an agreement with another DC (e.g. another business) and A1 decides they don't want the resources and return a reject message. DC has lost ?10,000 of income it could have made because of the protocol it is using. If A1 is a proxy for a competitor of DC it could repeatedly keep asking for offers it never intends to agree to meaning DC may loose revenue... Dominic: before I comment further on your proposed protocol what semantics are you attaching to the 'offer' message that the AR returns to the AI? Does the offer mean 'if you accept I will guarantee providing what is contained in this offer' or does it mean something else? Michael. [1] http://www.cs.cornell.edu/courses/cs614/2004sp/papers/Ske81.pdf [2] http://blogs.msdn.com/pathelland/archive/2007/05/20/soa-and- newton-s-universe.aspx [3] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants- don-t-use-erasers.aspx [4] http://betathoughts.blogspot.com/2007/06/brief-history-of- consensus-2pc-and.html [5] http://en.wikipedia.org/wiki/Two-phase_commit [6] www.iids.org/publications/scpe06.pdf From O.F.Rana at cs.cardiff.ac.uk Fri Aug 24 03:53:35 2007 From: O.F.Rana at cs.cardiff.ac.uk (Omer F Rana) Date: Fri, 24 Aug 2007 09:53:35 +0100 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> Message-ID: <20070824085335.GB27499@lapis.cs.cf.ac.uk> Hi Michael, Thanks for these excellent references -- will be downloading and reading them. My undersstanding of the Mobach et al. paper -- and the reason the 2PC approach was chosen was to satisfy legal constraints that they were working on. Their aim was more to ensure that legally both parties were covered, more than looking into the specifics of constraints of a distributed implementation. I am copying David Mobach and Benno Overeinder. regards Omer On Fri, Aug 24, 2007 at 10:35:50AM +0200, Michael Parkin wrote: > Toshi, Dominic, > > As no-one else has replied... > > On 23 Aug 2007, at 15:30, Toshiyuki Nakata wrote: > > >> So, yes, there are problems but it looks like a lot of people want to > >> have this extra commit message. Are there any written records on the > >> pros and cons of having the 2PC? > > > > I think this info. is very important. > > A 2PC-type protocol works well when you control everything. However, > where autonomous services are involved in (possibly) different > administrative domains (such as in a business environment) the cons > of using the 2PC style in agreements like this are well understood, > for example: > > * Skeen's paper [1] on commit protocols describes why 2PC is a > blocking protocol. > > * Pat Helland (formally Amazon, now Microsoft) describes the 2PC > protocol as the "anti-availability protocol" [2] because of the fact > it can block the transaction manager (Dominic, this would be the AR > in your protocol). As he says: "[2pc] is best used sparingly". > > (Toshi - I also direct you to his article on "accountants don't use > erasers" [3] about why agreements should not be overwritten). > > * Mark McKeown also has a blog article [4] about the difficulty of > distributed consensus, which is essentially what you're trying to > achieve (FTA: "consensus was originally called agreement"). > > * If you want a lighter read the Wikipedia article [5] also discusses > 2PC's blocking. > > About the Mobach, et. al. paper [6] - the last three steps in Figure > 2.4 are a 2PC-type protocol. When the 'DC' (from the paper) returns > the 'agreement offer' to 'A' they are blocked from offering those > resources to anyone else (although this is an assumption because the > paper doesn't say explicitly what the 'agreement offer' actually means). > > Imagine the scenario: DC returns an offer to A1 saying 'these > resources for ?10". Meanwhile A2, who is prepared to pay ?10,000 for > the same resources cannot make the agreement because DC has offered > them to A1. A2 then goes and makes an agreement with another DC (e.g. > another business) and A1 decides they don't want the resources and > return a reject message. DC has lost ?10,000 of income it could have > made because of the protocol it is using. > > If A1 is a proxy for a competitor of DC it could repeatedly keep > asking for offers it never intends to agree to meaning DC may loose > revenue... > > Dominic: before I comment further on your proposed protocol what > semantics are you attaching to the 'offer' message that the AR > returns to the AI? Does the offer mean 'if you accept I will > guarantee providing what is contained in this offer' or does it mean > something else? > > Michael. > > [1] http://www.cs.cornell.edu/courses/cs614/2004sp/papers/Ske81.pdf > [2] http://blogs.msdn.com/pathelland/archive/2007/05/20/soa-and- > newton-s-universe.aspx > [3] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants- > don-t-use-erasers.aspx > [4] http://betathoughts.blogspot.com/2007/06/brief-history-of- > consensus-2pc-and.html > [5] http://en.wikipedia.org/wiki/Two-phase_commit > [6] www.iids.org/publications/scpe06.pdf > > -- > graap-wg mailing list > graap-wg at 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 From parkinm at cs.man.ac.uk Fri Aug 24 05:41:11 2007 From: parkinm at cs.man.ac.uk (Michael Parkin) Date: Fri, 24 Aug 2007 12:41:11 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <20070824085335.GB27499@lapis.cs.cf.ac.uk> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824085335.GB27499@lapis.cs.cf.ac.uk> Message-ID: <4E37A998-1A26-4DD6-BA1E-C06B41688326@cs.man.ac.uk> Hi Omer, Thanks for your reply. On 24 Aug 2007, at 10:53, Omer F Rana wrote: > My undersstanding of the Mobach et al. paper -- and the reason the > 2PC > approach was chosen was to satisfy legal constraints that they were > working on. > Their aim was more to ensure that legally both parties were > covered, more than > looking into the specifics of constraints of a distributed > implementation. I believe that the legal, distributed computing _and_ business aspects of agreement must be considered together to design a successful contract negotiation and formation protocol - they cannot be considered separately. When all three aspects are taken into account together it is clear that 2PC-type protocols are inappropriate for cross-administrative domain negotiation because of the risk of blocking that is introduced, as I described in my previous email. Work we have done [1] together with the School of Law at Manchester University investigates maintaining the legalities of contract negotiation and formation (including adhering to the EU's e-Commerce directive) whilst still allowing the entity supplying the resources/ services not to be blocked, thus satisfying the requirements of business. Section 4.1 of the linked paper discusses blocking. Dean Kuo (who many of you know...[2]) and I are writing up and formally specifying the protocol we derived from this work and will be submitting this work for publication soon. Michael. [1] http://www2.cs.man.ac.uk/~parkinm/publications/ eChallenges_e2006_ref_235.pdf [2] http://www.cs.man.ac.uk/~dkuo/ From karlcz at univa.com Fri Aug 24 04:54:52 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 24 Aug 2007 16:54:52 +0700 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <000801c7e589$c704f6a0$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> Message-ID: <20070824095452.GA3811@granite.bbswl> On Aug 23, Toshiyuki Nakata modulated: > Hi Dominic: > > So, yes, there are problems but it looks like a lot of people want to > > have this extra commit message. Are there any written records on the > > pros and cons of having the 2PC? > > I think this info. is very important. > Unfortunately, I am not able to address this issue. > > Karl or others, please respond.. I definitely don't want to repeat the debate which is in the GRAAP-WG email archives, but let me just summarize what I think were the final observations and conclusions. WS-Agreement is aimed at a distributed, soft real-time (one might say isochronous) environment with limited trust between peers with bounded rationality. In other words, it is for establishing automated agreement between programmatic systems in an Internet-type environment where the agreement terms may involve wall-clock obligations which are at the root of the problem. When you boil it all down, there is always going to be a synchronization hazard where due to communication delays or faults, or even intentional decision delays, one party does not know whether the other has accepted the agreement and therefore is at risk to perform according to the terms of agreement when not necessary, or ignore the terms of agreement when bound by them. WS-Agreement formalizes this hazard to always place the burden on the agreement initiator who makes an offer and is bound by it if the responder accepts. Early drafts, derived from our SNAP work, had an extra signalling step to allow a sort of "pre-initiator" called an invitation. The group felt that this was too complicated to pursue, particularly because it could be approximated via advertisement. An invitation or advertisement would be a non-binding expression of interest in receiving agreement offers, so that the typical client-server roles could be reversed somewhat. The only difference is that an invitation is seen as usually a 1:1 relationship while an advertisement is 1:many. However, due to the non-binding nature of these signals and the assumption of bounded rationality (we can ignore the possibility of bluffing and other psychological strategies), I am not sure these differences are significant. For privacy, one could imagine secure advertisement channels (with authorization) to further blur the boundaries. Furthermore, 2PC can be synthesized with two WS-Agreement round-trips and an appropriate domain-specific agreement semantics. So, either advance reservation, combined with the right cost/penalty model, or the underlying invitation system can both look like 2PC in practice: 1.a. initiator offers advance reservation, OR 1.b. advertiser publishes interest after this first stage, both parties are aware of interest and primed to negotiate... 2.a. responder accepts (or rejects) reservation offer, OR 2.b. initiator offers against advertisement (or ignores it) after this stage, one party is obligated to satisfy and the other has a choice to make... (For the advance reservation, the initiator has a choice because the reservation includes a cost model with cheap cancellation under reasonable deadlines). 3.a. initiator offers claiming agreement (or cancels reservation), OR 3.b. responder accepts offer (or rejects it) after this stage, both parties are obligated to satisfy... 4.a. responder accepts claiming agreement (or acknowledges cancellation), OR 4.b. initiator acknowledges receipt (e.g. transport-level ACK) after this stage, both parties actually know what the other knows... In case it isn't obvious, advertisement is done via WS-Agreement templates and advance reservation followed by claiming is anticipated in the usage scenario examples as well. > Best Regards > Toshi > ----- > Toshiyuki Nakata ?????? > Executive Chief Engineer, Central Research Lab. NEC > 1753, Shimonumabe, Nakahara-Ku, > Kawasaki,Kanagawa 211-8666,Japan > Tel +81-44-431-7653 (NEC Internal 22-60035) > Fax +81-44-431-7609 (NEC Internal 22-60509) > karl p.s. I will add that the fundamental challenge I see for GRAAP-WG and WS-Agreement is that everyone approaches it with the same natural (but incorrect) intuitions about trust, signalling, and consensus. I think there is still a large social experiment to see who can deploy systems which are actually performing distributed agreement without a central authority... economics and our real-life world says it should work, most of the time at least. :-) -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From o.f.rana at cs.cardiff.ac.uk Fri Aug 24 06:09:14 2007 From: o.f.rana at cs.cardiff.ac.uk (Omer F. Rana) Date: Fri, 24 Aug 2007 12:09:14 +0100 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <4E37A998-1A26-4DD6-BA1E-C06B41688326@cs.man.ac.uk> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824085335.GB27499@lapis.cs.cf.ac.uk> <4E37A998-1A26-4DD6-BA1E-C06B41688326@cs.man.ac.uk> Message-ID: <46CEBC5A.1000707@cs.cardiff.ac.uk> Hi Michael, Yes, I off course agree with your statement that all three must be taken into consideration. In practice, many implementations do not follow this line however -- but they should. I guess there is a trade off between making the protocol too complex -- so much so that no one will actually use it -- vs. making it complete -- so that it takes account of everything that is useful. But you are right. Thanks also for the additional links. Seems like I have my reading set out for this w/end. regards Omer Michael Parkin wrote: > Hi Omer, > > Thanks for your reply. > > On 24 Aug 2007, at 10:53, Omer F Rana wrote: > > >> My undersstanding of the Mobach et al. paper -- and the reason the >> 2PC >> approach was chosen was to satisfy legal constraints that they were >> working on. >> Their aim was more to ensure that legally both parties were >> covered, more than >> looking into the specifics of constraints of a distributed >> implementation. >> > > I believe that the legal, distributed computing _and_ business > aspects of agreement must be considered together to design a > successful contract negotiation and formation protocol - they cannot > be considered separately. When all three aspects are taken into > account together it is clear that 2PC-type protocols are > inappropriate for cross-administrative domain negotiation because of > the risk of blocking that is introduced, as I described in my > previous email. > > Work we have done [1] together with the School of Law at Manchester > University investigates maintaining the legalities of contract > negotiation and formation (including adhering to the EU's e-Commerce > directive) whilst still allowing the entity supplying the resources/ > services not to be blocked, thus satisfying the requirements of > business. Section 4.1 of the linked paper discusses blocking. > > Dean Kuo (who many of you know...[2]) and I are writing up and > formally specifying the protocol we derived from this work and will > be submitting this work for publication soon. > > Michael. > > [1] http://www2.cs.man.ac.uk/~parkinm/publications/ > eChallenges_e2006_ref_235.pdf > [2] http://www.cs.man.ac.uk/~dkuo/ > > -- > graap-wg mailing list > graap-wg at 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 From t-nakata at cw.jp.nec.com Fri Aug 24 06:35:18 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 24 Aug 2007 20:35:18 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> Message-ID: <003401c7e642$d91f36c0$b084380a@Sakurai> Michael: Thank you very much for a thorough introduction of the current art. As Omer says, I'll also study some of the documents which I had not known before.. ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Michael Parkin [mailto:parkinm at cs.man.ac.uk] > Sent: Friday, August 24, 2007 5:36 PM > To: Toshiyuki Nakata; Dominic Battre > Cc: GRAAP-WG > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiating an established Agreement > > Toshi, Dominic, > > As no-one else has replied... > > On 23 Aug 2007, at 15:30, Toshiyuki Nakata wrote: > > >> So, yes, there are problems but it looks like a lot of > people want to > >> have this extra commit message. Are there any written > records on the > >> pros and cons of having the 2PC? > > > > I think this info. is very important. > > A 2PC-type protocol works well when you control everything. However, > where autonomous services are involved in (possibly) different > administrative domains (such as in a business environment) the cons > of using the 2PC style in agreements like this are well understood, > for example: > > * Skeen's paper [1] on commit protocols describes why 2PC is a > blocking protocol. > > * Pat Helland (formally Amazon, now Microsoft) describes the 2PC > protocol as the "anti-availability protocol" [2] because of the fact > it can block the transaction manager (Dominic, this would be the AR > in your protocol). As he says: "[2pc] is best used sparingly". > > (Toshi - I also direct you to his article on "accountants don't use > erasers" [3] about why agreements should not be overwritten). > > * Mark McKeown also has a blog article [4] about the difficulty of > distributed consensus, which is essentially what you're trying to > achieve (FTA: "consensus was originally called agreement"). > > * If you want a lighter read the Wikipedia article [5] also > discusses > 2PC's blocking. > > About the Mobach, et. al. paper [6] - the last three steps in Figure > 2.4 are a 2PC-type protocol. When the 'DC' (from the paper) returns > the 'agreement offer' to 'A' they are blocked from offering those > resources to anyone else (although this is an assumption because the > paper doesn't say explicitly what the 'agreement offer' > actually means). > > Imagine the scenario: DC returns an offer to A1 saying 'these > resources for ?10". Meanwhile A2, who is prepared to pay ?10,000 for > the same resources cannot make the agreement because DC has offered > them to A1. A2 then goes and makes an agreement with another > DC (e.g. > another business) and A1 decides they don't want the resources and > return a reject message. DC has lost ?10,000 of income it could have > made because of the protocol it is using. > > If A1 is a proxy for a competitor of DC it could repeatedly keep > asking for offers it never intends to agree to meaning DC may loose > revenue... > > Dominic: before I comment further on your proposed protocol what > semantics are you attaching to the 'offer' message that the AR > returns to the AI? Does the offer mean 'if you accept I will > guarantee providing what is contained in this offer' or does it mean > something else? > > Michael. > > [1] http://www.cs.cornell.edu/courses/cs614/2004sp/papers/Ske81.pdf > [2] http://blogs.msdn.com/pathelland/archive/2007/05/20/soa-and- > newton-s-universe.aspx > [3] http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants- > don-t-use-erasers.aspx > [4] http://betathoughts.blogspot.com/2007/06/brief-history-of- > consensus-2pc-and.html > [5] http://en.wikipedia.org/wiki/Two-phase_commit > [6] www.iids.org/publications/scpe06.pdf > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070824/e80831d7/attachment.bin From t-nakata at cw.jp.nec.com Fri Aug 24 06:41:09 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 24 Aug 2007 20:41:09 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement In-Reply-To: <20070824095452.GA3811@granite.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> Message-ID: <004101c7e643$a9f15030$b084380a@Sakurai> Karl: thank you very much for the excellent summary. (which I must admit I would need a week to really digest.). One thing that I (and I think you also pointed out ) was that that in the case of AR not agreeing, there were not enough hints for the AI to initiate another request.. Any comments on this? #Also comments to show stopper #7 would be very much appreciated :-) Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Karl Czajkowski [mailto:karlcz at univa.com] > Sent: Friday, August 24, 2007 6:55 PM > To: Toshiyuki Nakata > Cc: 'Dominic Battre'; 'GRAAP-WG' > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiating anestablished Agreement > > On Aug 23, Toshiyuki Nakata modulated: > > Hi Dominic: > > > So, yes, there are problems but it looks like a lot of > people want to > > > have this extra commit message. Are there any written > records on the > > > pros and cons of having the 2PC? > > > > I think this info. is very important. > > Unfortunately, I am not able to address this issue. > > > > Karl or others, please respond.. > > I definitely don't want to repeat the debate which is in the GRAAP-WG > email archives, but let me just summarize what I think were the final > observations and conclusions. > > WS-Agreement is aimed at a distributed, soft real-time (one might say > isochronous) environment with limited trust between peers with bounded > rationality. In other words, it is for establishing automated > agreement between programmatic systems in an Internet-type environment > where the agreement terms may involve wall-clock obligations which are > at the root of the problem. > > When you boil it all down, there is always going to be a > synchronization hazard where due to communication delays or faults, or > even intentional decision delays, one party does not know whether the > other has accepted the agreement and therefore is at risk to perform > according to the terms of agreement when not necessary, or ignore the > terms of agreement when bound by them. > > WS-Agreement formalizes this hazard to always place the burden on the > agreement initiator who makes an offer and is bound by it if the > responder accepts. Early drafts, derived from our SNAP work, had an > extra signalling step to allow a sort of "pre-initiator" called an > invitation. The group felt that this was too complicated to pursue, > particularly because it could be approximated via advertisement. > > An invitation or advertisement would be a non-binding expression of > interest in receiving agreement offers, so that the typical > client-server roles could be reversed somewhat. The only difference > is that an invitation is seen as usually a 1:1 relationship while an > advertisement is 1:many. However, due to the non-binding nature of > these signals and the assumption of bounded rationality (we can ignore > the possibility of bluffing and other psychological strategies), I am > not sure these differences are significant. For privacy, one could > imagine secure advertisement channels (with authorization) to further > blur the boundaries. > > Furthermore, 2PC can be synthesized with two WS-Agreement round-trips > and an appropriate domain-specific agreement semantics. So, either > advance reservation, combined with the right cost/penalty model, or > the underlying invitation system can both look like 2PC in practice: > > 1.a. initiator offers advance reservation, OR > 1.b. advertiser publishes interest > > after this first stage, both parties are aware of interest and primed > to negotiate... > > 2.a. responder accepts (or rejects) reservation offer, OR > 2.b. initiator offers against advertisement (or ignores it) > > after this stage, one party is obligated to satisfy and the other has > a choice to make... (For the advance reservation, the initiator has a > choice because the reservation includes a cost model with cheap > cancellation under reasonable deadlines). > > 3.a. initiator offers claiming agreement (or cancels > reservation), OR > 3.b. responder accepts offer (or rejects it) > > after this stage, both parties are obligated to satisfy... > > 4.a. responder accepts claiming agreement (or acknowledges > cancellation), OR > 4.b. initiator acknowledges receipt (e.g. transport-level ACK) > > after this stage, both parties actually know what the other knows... > > In case it isn't obvious, advertisement is done via WS-Agreement > templates and advance reservation followed by claiming is anticipated > in the usage scenario examples as well. > > > > Best Regards > > Toshi > > ----- > > Toshiyuki Nakata ?????? > > Executive Chief Engineer, Central Research Lab. NEC > > 1753, Shimonumabe, Nakahara-Ku, > > Kawasaki,Kanagawa 211-8666,Japan > > Tel +81-44-431-7653 (NEC Internal 22-60035) > > Fax +81-44-431-7609 (NEC Internal 22-60509) > > > > > karl > > p.s. I will add that the fundamental challenge I see for GRAAP-WG and > WS-Agreement is that everyone approaches it with the same natural (but > incorrect) intuitions about trust, signalling, and consensus. I think > there is still a large social experiment to see who can deploy systems > which are actually performing distributed agreement without a central > authority... economics and our real-life world says it should work, > most of the time at least. :-) > > -- > Karl Czajkowski > Software Architect > > Univa Corporation > 1001 Warrenville Road, Suite 550 > Lisle, IL 60532 > > karlcz at univa.com > www.univa.com > ________________________________________________________________ > www.univa.com. > > The Leaders of Open Source Cluster and Grid Software -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070824/8f66b2a6/attachment.bin From karlcz at univa.com Fri Aug 24 06:51:45 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 24 Aug 2007 18:51:45 +0700 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement In-Reply-To: <004101c7e643$a9f15030$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <004101c7e643$a9f15030$b084380a@Sakurai> Message-ID: <20070824115145.GB3811@granite.bbswl> On Aug 24, Toshiyuki Nakata modulated: > Karl: > thank you very much for the excellent summary. > (which I must admit I would need a week to really digest.). > > One thing that I (and I think you also pointed out ) was that that > in the case of AR not agreeing, there were not enough hints > for the AI to initiate another request.. > > Any comments on this? > Well, my practical view, keeping in mind bounded-rationality systems, is that if the template was insufficient to guide you to an acceptable agreement offer, then a "hint" would not fair any better. Either the advertiser announces its policies/restrictions in detail sufficient to create an agreement, or it does not. Why would it reveal more information on the next iteration? If you're trying to address intelligent parties who do bluffing and bartering, then your problem is out of scope for WS-Agreement... Another intractable problem is that the resource manager making the decision may not even be able to formulate a specific reason for "why it didn't match", e.g. in a scheduler that is matching many properties at once against a dynamic load of competing requests, it is not necessarily easy to determine what would need to change to make a request get handled above other requests. Furthermore, it would have race conditions since the dynamic load may be different by the time the next offer arrives. So I think in practice, an automated WS-Agreement initiator is going to operate with some narrowly-defined commodity offers and try fallback, retry, and fail-over among responders. If this fails, offline analysis and problem determination will be required to understand what went wrong, and how to improve templates and offering systems to avoid these doomed offers. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From parkinm at cs.man.ac.uk Fri Aug 24 07:30:38 2007 From: parkinm at cs.man.ac.uk (Michael Parkin) Date: Fri, 24 Aug 2007 14:30:38 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <20070824095452.GA3811@granite.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> Message-ID: <61673AE7-4829-4E26-8D07-A002966284DF@cs.man.ac.uk> Hi Karl, Sorry, I have a couple of quick questions/observations... Apologies in advance if I have misunderstood anything in your email as sometimes happens. On 24 Aug 2007, at 11:54, Karl Czajkowski wrote: > ... However, due to the non-binding nature of > these signals and the assumption of bounded rationality (we can ignore > the possibility of bluffing and other psychological strategies), I am > not sure these differences are significant. For privacy, one could > imagine secure advertisement channels (with authorization) to further > blur the boundaries. Are you saying that 'bluffing and other psychological strategies' can be ignored in the negotiation protocol that is used or in the negotiation strategy of each participant? For me, these two aspects of reaching agreement are orthogonal, just like they are in (for example) contract law. > Furthermore, 2PC can be synthesized with two WS-Agreement round-trips > and an appropriate domain-specific agreement semantics. So, either > advance reservation, combined with the right cost/penalty model, or > the underlying invitation system can both look like 2PC in practice: > > 1.a. initiator offers advance reservation, OR > 1.b. advertiser publishes interest > > after this first stage, both parties are aware of interest and primed > to negotiate... > > 2.a. responder accepts (or rejects) reservation offer, OR > 2.b. initiator offers against advertisement (or ignores it) > > after this stage, one party is obligated to satisfy and the other has > a choice to make... (For the advance reservation, the initiator has a > choice because the reservation includes a cost model with cheap > cancellation under reasonable deadlines). > > 3.a. initiator offers claiming agreement (or cancels > reservation), OR > 3.b. responder accepts offer (or rejects it) So far you have the messages: offer, advert, cancel, accept and reject... all of which are clear to me. But can you explain what the 'offers claiming agreement' step (3a) is? I'm sorry, I don't understand what this means - is it an offer, accept or another message being sent from the initiator to the responder? > p.s. I will add that the fundamental challenge I see for GRAAP-WG and > WS-Agreement is that everyone approaches it with the same natural (but > incorrect) intuitions about trust, signalling, and consensus. Can you explain some more about what you think these shared (but incorrect) intuitions are? My intuition is to a) trust no-one, b) assume messages ('signals') can be lost, duplicated and re-ordered and c) assume that consensus may or not be reached - it depends :-). Are these the same as yours and/or GRAAP-WG's? Thanks, Michael. From karlcz at univa.com Fri Aug 24 07:57:26 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 24 Aug 2007 19:57:26 +0700 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <61673AE7-4829-4E26-8D07-A002966284DF@cs.man.ac.uk> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <61673AE7-4829-4E26-8D07-A002966284DF@cs.man.ac.uk> Message-ID: <20070824125726.GC3811@granite.bbswl> On Aug 24, Michael Parkin modulated: > Hi Karl, > > Sorry, I have a couple of quick questions/observations... Apologies > in advance if I have misunderstood anything in your email as > sometimes happens. > > On 24 Aug 2007, at 11:54, Karl Czajkowski wrote: > > > > >... However, due to the non-binding nature of > >these signals and the assumption of bounded rationality (we can ignore > >the possibility of bluffing and other psychological strategies), I am > >not sure these differences are significant. For privacy, one could > >imagine secure advertisement channels (with authorization) to further > >blur the boundaries. > > Are you saying that 'bluffing and other psychological strategies' can > be ignored in the negotiation protocol that is used or in the > negotiation strategy of each participant? For me, these two aspects > of reaching agreement are orthogonal, just like they are in (for > example) contract law. > I am saying that we were not considering such strategies as relevant and therefore did not care to have multi-round negotiation to try to support them. It was assumed that someone who did care about these might propose further specifications that might reuse some of the agreement data models from WS-Agreement. > So far you have the messages: offer, advert, cancel, accept and > reject... all of which are clear to me. > > But can you explain what the 'offers claiming agreement' step (3a) > is? I'm sorry, I don't understand what this means - is it an offer, > accept or another message being sent from the initiator to the > responder? > We have always assumed a notion of chaining agreements, e.g. part of the context of an agreement could be another agreement. In the fully agreement-based advance reservation case, the idiom is that you first get an 'advance reservation' agreement and you then follow it up with one or more 'claiming' agreements. The claiming agreement binds the reservation of resource capabilities to a particular use. There are other usage scenarios where the claiming/binding occurs in other domain-specific protocols instead of via claiming agreements. So it is another offer, with agreement terms which reference the existing reservation agreement. It is implicitly understood that the reservation agreement gives you the "right" to make these claims, subject to the finite capacity limits of the reservation. In essence, the entire reserve+claim process is the 2PC protocol for the actual domain specific agreement on the consumption of resources. You might note, this does imply a general form of multi-round negotiation, if you were to construct domain-specific terms which could refine or augment an existing agreement with more information. Once you had an agreement which could claim on an existing agreement and add more agreeable terms, you could converge towards the point of maximum/optimal agreement, starting with more conservative terms... however, no effort has been put into formalizing such term languages, outside the conventional advance reservation models we inherited into this work. > > > >p.s. I will add that the fundamental challenge I see for GRAAP-WG and > >WS-Agreement is that everyone approaches it with the same natural (but > >incorrect) intuitions about trust, signalling, and consensus. > > Can you explain some more about what you think these shared (but > incorrect) intuitions are? > > My intuition is to a) trust no-one, b) assume messages ('signals') > can be lost, duplicated and re-ordered and c) assume that consensus > may or not be reached - it depends :-). Are these the same as yours > and/or GRAAP-WG's? > You're ahead of the game, I'd say. :-) The typical intuition people have is that consensus can be reached easily, discounting the byzantine faults of the Internet environment, and having a naive understanding of what agreement and commitment really mean. I have lost track of the number of times people have wanted to jump into the most elaborate negotiation strategies they've ever witnessed in real life, without considering: 1. The messaging (un)reliability model you mention. 2. The difference between intelligent and machine agents in terms of their ability to reason and game one another. 3. The difference between contracts signed by legally responsible entities and the automatic decisions of machines. 4. The realities of over-subscription and risk balancing in realistic economic environments (e.g. dealing in real numbered costs and benefits instead of hard absolutes). 5. The desired/expected/acceptable behavior for a large-scale system with many of their proposed agents functioning simultaneously. What I see is that people who focus on this area intensely will all eventually start to see the same general solutions, but these are not very compatible with what the naive user wants. So real deployment faces the challenge of users who do not appreciate the value of these systems nor the theoretical impossibility of what they desire. > > Michael. > karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From bjo at cs.vu.nl Fri Aug 24 08:08:04 2007 From: bjo at cs.vu.nl (Benno Overeinder) Date: Fri, 24 Aug 2007 15:08:04 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46CEBC5A.1000707@cs.cardiff.ac.uk> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824085335.GB27499@lapis.cs.cf.ac.uk> <4E37A998-1A26-4DD6-BA1E-C06B41688326@cs.man.ac.uk> <46CEBC5A.1000707@cs.cardiff.ac.uk> Message-ID: <9661A103-DDE3-4D1A-B091-4E613F347A65@cs.vu.nl> Hi Omer and Michael, Maybe late, but here is my 2 ct. contribution to the discussion of the 2 phase commit protocol used in our extended WS-Agreement implementation. I agree with Michael's analysis of the fundamental problems with 2PC in its blocking behaviour. Indeed, the cited references give a good overview of the problems with 2PC. The other argument of missing revenue when two offers arrive just after each other: while processing the 10 euro offer, the 10,000 offer might be rejected (by short of resources), and eventually the 10 euro offer is not committed. I think this problem is not specific to our approach, with any negotiation/obligation you can miss revenues if better offers, while engaged with a partner who might bail-out. Do you know of other negotiation strategies/policies that does not suffer from this? We can solve this in our framework by supporting re-negotiation, if a better offer arrives, the resource owner can start a re-negotiation with the current resource users. The problem of a denial-of-service attack (by proxy) is serious in any system where resources are allocated to the (un-) successful negotiation process (either by reserving resources or the use of computing resources by the protocol itself). In the paper, we did not include the details of authentication and trust, but this is included in the implementation of the framework. Repeated malicious behaviour will be punished and requests will not be considered. We chose to use 2PC, as it is a simple extension to the WS-Agreement protocol (and can be made compatible/interoperable by just skipping the last two steps). We did not want to redesign the WS-Agreement protocol, but include some primitive means for negotiation other than one-shot negotiaton (think of contractNet), and both parties commit to an agreement for legal purposes (as Omer explained). I will definitely look into your work with Dean Kuo. On Aug 24, 2007, at 1:09 PM, Omer F. Rana wrote: > Hi Michael, > > Yes, I off course agree with your statement that all three must be > taken > into consideration. In practice, many > implementations do not follow this line however -- but they should. > > I guess there is a trade off between making the protocol too > complex -- > so much so that no one will actually > use it -- vs. making it complete -- so that it takes account of > everything that is useful. But you are right. > > Thanks also for the additional links. Seems like I have my reading set > out for this w/end. > > regards > Omer > > Michael Parkin wrote: >> Hi Omer, >> >> Thanks for your reply. >> >> On 24 Aug 2007, at 10:53, Omer F Rana wrote: >> >> >>> My undersstanding of the Mobach et al. paper -- and the reason the >>> 2PC >>> approach was chosen was to satisfy legal constraints that they were >>> working on. >>> Their aim was more to ensure that legally both parties were >>> covered, more than >>> looking into the specifics of constraints of a distributed >>> implementation. >>> >> >> I believe that the legal, distributed computing _and_ business >> aspects of agreement must be considered together to design a >> successful contract negotiation and formation protocol - they cannot >> be considered separately. When all three aspects are taken into >> account together it is clear that 2PC-type protocols are >> inappropriate for cross-administrative domain negotiation because of >> the risk of blocking that is introduced, as I described in my >> previous email. >> >> Work we have done [1] together with the School of Law at Manchester >> University investigates maintaining the legalities of contract >> negotiation and formation (including adhering to the EU's e-Commerce >> directive) whilst still allowing the entity supplying the resources/ >> services not to be blocked, thus satisfying the requirements of >> business. Section 4.1 of the linked paper discusses blocking. >> >> Dean Kuo (who many of you know...[2]) and I are writing up and >> formally specifying the protocol we derived from this work and will >> be submitting this work for publication soon. >> >> Michael. >> >> [1] http://www2.cs.man.ac.uk/~parkinm/publications/ >> eChallenges_e2006_ref_235.pdf >> [2] http://www.cs.man.ac.uk/~dkuo/ >> From o.f.rana at cs.cardiff.ac.uk Fri Aug 24 09:14:06 2007 From: o.f.rana at cs.cardiff.ac.uk (Omer F. Rana) Date: Fri, 24 Aug 2007 15:14:06 +0100 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement In-Reply-To: <20070824115145.GB3811@granite.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <004101c7e643$a9f15030$b084380a@Sakurai> <20070824115145.GB3811@granite.bbswl> Message-ID: <46CEE7AE.4080406@cs.cardiff.ac.uk> Hi Karl, Very interesthing thoughts. Just some quick comments below. Karl Czajkowski wrote: > Well, my practical view, keeping in mind bounded-rationality systems, > is that if the template was insufficient to guide you to an acceptable > agreement offer, then a "hint" would not fair any better. Either the > advertiser announces its policies/restrictions in detail sufficient to > create an agreement, or it does not. Why would it reveal more > information on the next iteration? If you're trying to address > intelligent parties who do bluffing and bartering, then your problem > is out of scope for WS-Agreement... > It is certainly possible that the detail contained in a template may increase in complexity as interaction between parties proceeds. For instance, one could consider a coarse-grained advertisement that identifies the types of capability that a provider offers, and not necessarily the ranges associated with those capabilities. The hint would then be a subsequent refinement of these capabilities in future interations. Yes, therefore there could be revelation of additional information in subsequent interactions. > Another intractable problem is that the resource manager making the > decision may not even be able to formulate a specific reason for "why > it didn't match", e.g. in a scheduler that is matching many properties > at once against a dynamic load of competing requests, it is not > necessarily easy to determine what would need to change to make a > request get handled above other requests. Furthermore, it would have > race conditions since the dynamic load may be different by the time > the next offer arrives. > Yes, agree about the matching problem. However, it is possible to rank matches (or mis-matches) using some "match distance" metric. This can range from a associating as weight with attributes that are of most significance to a particular party -- say, I am more interested in having a certain disk space rather than a specific processor speed. The way to deal with dynamic load -- as often undertaken in other performance prediction efforts -- is to deal with summary and aggregate data -- rather than raw data. Hence, one would base a prediction on average (or some other time-based aggregate statistic) rather than the value at a particular point in time. > So I think in practice, an automated WS-Agreement initiator is going > to operate with some narrowly-defined commodity offers and try > fallback, retry, and fail-over among responders. If this fails, > offline analysis and problem determination will be required to > understand what went wrong, and how to improve templates and offering > systems to avoid these doomed offers. > Yes, agree with this. In the abscence of well defined constraints, I can see a lot of problems with the approach. There are some automated approaches that can help with doing some of the post-failure analysis. regards Omer -- 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 From t-nakata at cw.jp.nec.com Sun Aug 26 20:53:24 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Mon, 27 Aug 2007 10:53:24 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> Message-ID: <009e01c7e84d$0e0605b0$b084380a@Sakurai> Many thanks to everyone who responded last week. I still have not grasped all the implications but have updated the Wiki (including adding the references Michael kindly provided.) to propose addressing the following issue. 1)new EPR or rewrite the old agreement => as Michael points out, accountants should not use erasers. Agreements as logs should not be erased/modified... This means concept of superceded should be added. In order to avoid racing conditions, Agreement state should be extended to allow transition from *observed* state to *is-being-superceded* followed by either *superceded* (if the agreement modification is agreed to) or *observed* state (if the agreement modification is not agreed to..) Best Regards Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070827/1536f060/attachment.bin From karlcz at univa.com Sun Aug 26 21:50:06 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 27 Aug 2007 09:50:06 +0700 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement In-Reply-To: <009e01c7e84d$0e0605b0$b084380a@Sakurai> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <009e01c7e84d$0e0605b0$b084380a@Sakurai> Message-ID: <20070827025006.GD3276@crater.bbswl> Toshi, I have the following comments/observations after reviewing your wiki page... sorry I have not been able to keep a close watch on the recent activities of the group. 1. The idea of negotiation of alternatives is difficult and I think requires a better negotiation protocol. After much debate, as I recall, we limited WS-Agreement to simple acceptance of an offer. If the offer has alternatives in it, then the responder is accepting to satisfy this compound expression in any way he sees fit, with no information about how, or indeed whether his solution might vary over time and be satisfied by different clauses in the compound rules! It would take domain-specific interpretation of the SDTs to somehow fix this solution, as there is nothing in the protocol to communicate a "lowering" or simplification of the alternatives expression. (For example, I anticipated that in a basic use of JSDL for a job term, the interpretation could be defined that the service terms are chosen at job-start time and frozen, as is a typical implementation requirement for HPC resources... you would know they are not time-varying, though there is still no facility to communicate which exact parameters were chosen.) What I would suggest is that you try to keep this aspect of negotiation protocol orthogonal to the underlying notion of renegotiation. First, work on the semantics for renegotiation of an agreement as you have done, e.g. replacement/superceding of an agreement. Then, admit that basic or advanced protocols could be used to negotiate either the initial or subsequent agreement. For example, a relatively simple renegotiation could adapt the existing factory pattern for both initial and subsequent negotiations. If a future specification provides a multi-round negotiation to lower/simplify abstract agreement constraints to a more concrete solution, this could replace the basic factory pattern in both cases too. 2. I think the idea of superceding an agreement is fine, but I have trouble seeing a distinction between this and the general use of agreements in the context of other agreements. For example, the advance reservation scenario allows "claiming" of a resource reservation, and you can interpret this as adjusting an initial resource agreement to include binding to an application, with the same results as if someone simply negotiated an application with the same QoS terms in one shot... What I would point out is that this claiming/context model allows many:many derivation of agreements in the general case. E.g. I could reserve a large resource (in space-time) and consume it with multiple applications which either run serially or in parallel. I could also combine several resources (in separate agreements) into a complex application. Couldn't a renegotiation also be temporary, e.g. "boost this resource reservation for the next hour, but then fall back to the previous terms"? I am not sure how "supercededby" would be applicable here. Is it worth having one more general metalanguage for discovery/navigation of agreements which are linked to other agreements? We could use the extensibility of the wsag:Context to enumerate the actual claimed or superseded agreements, and it seems useful to have a dynamic resource property which could provide reverse-lookup of new agreements which list an agreement in the new wsag:Context too. 3. Also, a general concern I have is that the discussions are not crisp about the uses of the agreement. The talk of race conditions makes me nervous, as it seems to combine denotation of service terms with the implementation of resource managers. In my view, WS-Agreement is completely focused on the establishment of terms between the two parties, and says nothing about how one of the parties is implementing the protocol. I do not see a necessary race condition for "supercededby" because I don't think the initiator (for example) needs to be aware of this state change in order to meaningfully express a claim against an agreement. If an agreement is renegotiated, it could still be usable for claiming by name, while the actual resource manager has to take into account that there are now aliases to the newly revised delivery terms... 4. The question of having "responder initiated renegotiation" was foreseen in the optional symmetric protocol mode. In essence, if EPRs are exchanged so that both parties have an EPR representing the other party's view of the agreement, then they can switch roles and become initiator for further rounds of communication. In order to use this feature, one would need to define an extension to the protocol, e.g. have the symmetric agreement resources support an extended protocol which includes the renegotiation operations as well as the basic monitoring/cancellation operations. I think it would be appropriate to define a new negotiation protocol as a profile on this feature, so that a specific SDT would demand the presence of a renegotiation facility which would then be available as extended operations and resource properties on the Agreement resource. Again, if we consider the fuzzy case of many:many renegotiations, the best approach might be a simple RP in the agreement that holds an EPR to the renegotiation service, thereby separating discovery (via lookup of this RP an existing agreement) from claiming/context references which might involve more than one agreement at a time. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From karlcz at univa.com Mon Aug 27 01:52:37 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 27 Aug 2007 13:52:37 +0700 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" Message-ID: <20070827065237.GG3276@crater.bbswl> Michael, I just read "Challenges in EU Grid Contracts" for the first time after seeing it linked from Toshi's wiki page updates. I thought it might be useful to address several topics in the paper regarding WS-Agreement, though I have a suspicion that some of these issues may have been addressed long ago by others... 1. There is an assertion that WS-Agreement does not support acknowledgement of receipt of an offer independent of the acceptance decision. This is incorrect, as the PendingAgreement construct is specifically defined for this purpose: the CreatePendingAgreement factory pattern returns an EPR to a PendingAgreement which is yet to be accepted or rejected. This feature was motivated by a different observation that a decision process might be too slow to perform during a SOAP-over-HTTP in/out message, but it equally addresses your concern of knowing that the offer was received before the decision process is complete. (A WS-* purist position could be that message acknowledgement is a transport-level problem rather than a SOAP problem, but we had to bow to the practical use of SOAP-over-HTTP...) 2. There is an allowance for external acceptance notification channels, though I admit this is not emphasized in the text. Present in the base protocol are the Acceptance port type and the agreement state resource property, both of which may be used simultaneously on the same agreement. It is the state model which allows for transitions to accepted state independent of the other protocol operations. There is nothing to disallow other notification paths such as email, facsimile, registered mail, etc. (but, see next issue). 3. A significant difference between WS-Agreement and the contract law model described in the paper is the moment of acceptance: in WS-Agreement, acceptance is defined as the moment the responder chooses to accept, and is not dependent on sending an acceptance message to the initiator. This difference becomes clear in unusual asynchronous/lossy message environments and/or contested agreements. This is a crucial technical point in WS-Agreement. In order to define the acceptance moment as when the acceptance is delivered to the initiator (as in your contract law discussion) would require a reliable delivery model where some trustworthy (third-party) observer can witness the delivery. At risk of confusing the terminology, a way to characterize such a variant of our protocol might be: 1. initiator sends offer to responder. 2. responder chooses to accept. 3. responder attempts to send acceptance notice. 4. reliable message channel observes delivery of (3) and acceptance is now true. Given our presumption of an Internet-like environment without any secure, third-party channel to "serve" notices, this does nothing more than "rotate" the participant roles by one unidirectional message. In effect, it is really the "initiator" in step (4) who decides acceptance by choosing to receive the acceptance notice or not, because it is not possible to prove that he received a message unless he acknowledges it! Thus, his offer is not really obligating, as he can shirk his responsibilities by choosing not to acknowledge the acceptance. Thus, I would say the above "contract law"-style sequence of: offer/accept/receipt-as-decision is indistinguishable in practice from: invite/offer/accept-as-decision As there must be some party in the system that first knows the decision before this information is distributed asynchronously to all parties, we make the responder be the observer! Finally, as I described it in a previous email. WS-Agreement supports this through the slightly more general: advertise/offer/accept-as-decision where you could restrict or otherwise optimize access to advertisements in order to effect a directed invitation. (It is considered somewhat out of scope for WS-Agreement to define how advertisements are retrieved, e.g. what sort of publishing or information dispersal architecture is used for discovery.) I hope this helps clarify the technical solution embodied in WS-Agreement. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From t-nakata at cw.jp.nec.com Mon Aug 27 03:25:43 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Mon, 27 Aug 2007 17:25:43 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiatinganestablished Agreement In-Reply-To: <20070827025006.GD3276@crater.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <009e01c7e84d$0e0605b0$b084380a@Sakurai> <20070827025006.GD3276@crater.bbswl> Message-ID: <002501c7e883$dc2328c0$b084380a@Sakurai> Karl: Thank you very much for a detailed comment on the wiki page. Please give me some time to digest and respond as I am out of cycles right now:-( Best Regards & Thank you very much Toshi ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Karl Czajkowski [mailto:karlcz at univa.com] > Sent: Monday, August 27, 2007 11:50 AM > To: Toshiyuki Nakata > Cc: 'Dominic Battre'; 'GRAAP-WG' > Subject: Re: [GRAAP-WG] Modification to the wiki Page on > Renegotiatinganestablished Agreement > > Toshi, I have the following comments/observations after reviewing your > wiki page... sorry I have not been able to keep a close watch on the > recent activities of the group. > > 1. The idea of negotiation of alternatives is difficult and I think > requires a better negotiation protocol. > > After much debate, as I recall, we limited WS-Agreement to simple > acceptance of an offer. If the offer has alternatives in it, then > the responder is accepting to satisfy this compound expression in > any way he sees fit, with no information about how, or indeed > whether his solution might vary over time and be satisfied by > different clauses in the compound rules! It would take > domain-specific interpretation of the SDTs to somehow fix this > solution, as there is nothing in the protocol to communicate a > "lowering" or simplification of the alternatives expression. (For > example, I anticipated that in a basic use of JSDL for a job term, > the interpretation could be defined that the service terms are > chosen at job-start time and frozen, as is a typical implementation > requirement for HPC resources... you would know they are not > time-varying, though there is still no facility to communicate > which exact parameters were chosen.) > > What I would suggest is that you try to keep this aspect of > negotiation protocol orthogonal to the underlying notion of > renegotiation. First, work on the semantics for renegotiation of > an agreement as you have done, e.g. replacement/superceding of an > agreement. Then, admit that basic or advanced protocols could be > used to negotiate either the initial or subsequent agreement. > > For example, a relatively simple renegotiation could adapt the > existing factory pattern for both initial and subsequent > negotiations. If a future specification provides a multi-round > negotiation to lower/simplify abstract agreement constraints to a > more concrete solution, this could replace the basic factory > pattern in both cases too. > > > 2. I think the idea of superceding an agreement is fine, but I have > trouble seeing a distinction between this and the general use of > agreements in the context of other agreements. For example, the > advance reservation scenario allows "claiming" of a resource > reservation, and you can interpret this as adjusting an initial > resource agreement to include binding to an application, with the > same results as if someone simply negotiated an application with > the same QoS terms in one shot... > > What I would point out is that this claiming/context model allows > many:many derivation of agreements in the general case. E.g. I > could reserve a large resource (in space-time) and consume it with > multiple applications which either run serially or in parallel. I > could also combine several resources (in separate agreements) into > a complex application. Couldn't a renegotiation also be temporary, > e.g. "boost this resource reservation for the next hour, but then > fall back to the previous terms"? > > I am not sure how "supercededby" would be applicable here. Is it > worth having one more general metalanguage for discovery/navigation > of agreements which are linked to other agreements? We could use > the extensibility of the wsag:Context to enumerate the actual > claimed or superseded agreements, and it seems useful to have a > dynamic resource property which could provide reverse-lookup of new > agreements which list an agreement in the new wsag:Context too. > > > 3. Also, a general concern I have is that the discussions are not > crisp about the uses of the agreement. The talk of race conditions > makes me nervous, as it seems to combine denotation of service > terms with the implementation of resource managers. In my view, > WS-Agreement is completely focused on the establishment of terms > between the two parties, and says nothing about how one of the > parties is implementing the protocol. I do not see a necessary > race condition for "supercededby" because I don't think the > initiator (for example) needs to be aware of this state change in > order to meaningfully express a claim against an agreement. If an > agreement is renegotiated, it could still be usable for claiming by > name, while the actual resource manager has to take into account > that there are now aliases to the newly revised delivery terms... > > > 4. The question of having "responder initiated renegotiation" was > foreseen in the optional symmetric protocol mode. In essence, if > EPRs are exchanged so that both parties have an EPR representing > the other party's view of the agreement, then they can switch roles > and become initiator for further rounds of communication. In order > to use this feature, one would need to define an extension to the > protocol, e.g. have the symmetric agreement resources support an > extended protocol which includes the renegotiation operations as > well as the basic monitoring/cancellation operations. > > I think it would be appropriate to define a new negotiation > protocol as a profile on this feature, so that a specific SDT would > demand the presence of a renegotiation facility which would then be > available as extended operations and resource properties on the > Agreement resource. > > Again, if we consider the fuzzy case of many:many renegotiations, > the best approach might be a simple RP in the agreement that holds > an EPR to the renegotiation service, thereby separating discovery > (via lookup of this RP an existing agreement) from claiming/context > references which might involve more than one agreement at a time. > > > karl > > > -- > Karl Czajkowski > Software Architect > > Univa Corporation > 1001 Warrenville Road, Suite 550 > Lisle, IL 60532 > > karlcz at univa.com > www.univa.com > ________________________________________________________________ > www.univa.com. > > The Leaders of Open Source Cluster and Grid Software > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070827/71449c5b/attachment.bin From mailinglists at battre.de Mon Aug 27 12:51:24 2007 From: mailinglists at battre.de (Dominic Battre) Date: Mon, 27 Aug 2007 19:51:24 +0200 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <20070824095452.GA3811@granite.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> Message-ID: <46D30F1C.9070604@battre.de> Hello, Thank you very much, Karl, for giving a lot of insight what is behind WS-Agreement. > Furthermore, 2PC can be synthesized with two WS-Agreement round-trips > and an appropriate domain-specific agreement semantics. So, either > advance reservation, combined with the right cost/penalty model, or > the underlying invitation system can both look like 2PC in practice: I tried to digest that and this is what I came up with: https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit (I used my wiki because it supports tables) It would be great, if you could have a brief look at it and tell me whether this is what you had in mind. If some people want to contribute, I'd be interested in starting to write a "Best Practices in WS-Agreement" / "Design Patterns in WS-Agreement" / "WS-Agreement cookbook" / ... document. This issue of 2PC for example would be a good candidate for such a document. I think it would really help if we find a place to collect examples, approaches of modeling something, approaches of implementing something, ... I could easily contribute lots of questions but maybe some answers as well. Best regards, Dominic From karlcz at univa.com Mon Aug 27 21:21:39 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 28 Aug 2007 09:21:39 +0700 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46D30F1C.9070604@battre.de> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <46D30F1C.9070604@battre.de> Message-ID: <20070828022139.GA29479@crater.bbswl> On Aug 27, Dominic Battre modulated: > I tried to digest that and this is what I came up with: > > https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit > > (I used my wiki because it supports tables) > > It would be great, if you could have a brief look at it and tell me > whether this is what you had in mind. > Well, your example looks like a solution with a new invitation message. The basic 2PC/advance reservation idiom, as already illustrated in the advance reservatione example in the spec, would be: Consumer Provider (as Initiator) (as Responder) a. discovery <--- template --- b. prepare --- createAgreement(SLA1) ---> <--- accept --- (or reject to abort preparation) c. commit --- createAgreement(SLA2) ---> <--- accept --- (reject would be a serious failure) The discovery phase (a) is not emphasized in WS-Agreement because it was assumed to be an area where OGSA would provide other solutions. The basic WSRF resource property model was considered sufficient to capture the template model and allow basic query, but one hopes there will be search services where a consumer could locate providers with relevant templates. It might also include other non-obligating queries regarding resource availability. The SLA1 in phase (b) is the advance reservation and captures the resource requirements that are needed for the co-allocation. Due to the limited negotiation model in WS-Agreement, the co-allocation solution must already be concretely proposed here, e.g. the time of resource availability is part of the SLA1 terms, since the consumer/initiator has to make consistent advance reservation proposals to all providers involved in the transaction. The only answer available in the protocol is "yes/no" as to whether they can prepare as requested in SLA1. (If you are looking for a proposal/counter-offer pattern, that is an entirely different issue than this 2PC synchronization. That, indeed, requires a new negotiation protocol, though it is possible to define was as an extension or complement to WS-Agreement.) If preparation fails, the initiator can cancel/destroy any existing reservations to abort the 2PC transaction. Therefore, as I mentioned previously, a cost model with cheap advance reservation+cancellation is required to allow this idiom. One would expect that the cost of reservation goes up the longer it is held, e.g. to discourage aggressive use of 2PC resulting in live-lock of resources. The SLA2 in phase (c) is the actual "job" or whatever was intended to be co-scheduled. It makes claims on the appropriate SLA1 which should mean that the provider is obligated to accept this claim, since he already promised the resources. Thus, rejection at this time is unexpected and indicates a violation, so the 2PC semantics would fall apart here. (Note, this is no different than any other way that a non-trusted/partially-trusted party could choose to violate 2PC protocols.) karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From parkinm at cs.man.ac.uk Tue Aug 28 02:50:14 2007 From: parkinm at cs.man.ac.uk (parkinm at cs.man.ac.uk) Date: 28 Aug 2007 08:50:14 +0100 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: <20070827065237.GG3276@crater.bbswl> References: <20070827065237.GG3276@crater.bbswl> Message-ID: Hi Karl, Thanks for taking the time to read our paper. On Aug 27 2007, Karl Czajkowski wrote: > Michael, I just read "Challenges in EU Grid Contracts" for the first > time after seeing it linked from Toshi's wiki page updates. I thought > it might be useful to address several topics in the paper regarding > WS-Agreement, though I have a suspicion that some of these issues may > have been addressed long ago by others... Maybe they have been addressed long ago, but they aren't clear (to me anyway) from the spec and as someone who wasn't involved in the specification process. > 1. There is an assertion that WS-Agreement does not support > acknowledgement of receipt of an offer independent of the > acceptance decision. This is incorrect, as the PendingAgreement > construct is specifically defined for this purpose: the > CreatePendingAgreement factory pattern returns an EPR to a > PendingAgreement which is yet to be accepted or rejected. > > This feature was motivated by a different observation that a > decision process might be too slow to perform during a > SOAP-over-HTTP in/out message, but it equally addresses your > concern of knowing that the offer was received before the decision > process is complete. (A WS-* purist position could be that message > acknowledgement is a transport-level problem rather than a SOAP > problem, but we had to bow to the practical use of > SOAP-over-HTTP...) Yes, I agree. The pending state (though personally I think 'received offer' is clearer) can be used to run tasks scheduling algorithms, for instance, like our paper says. However, I don't think a message acknowledgement (in its most general sense) is "a transport-level problem" (I'm not sure if you were agreeing or disagreeing to this point and what your reference to SOAP/HTTP means - it isn't clear). For example, how do I know that a service didn't crash between the transport-level message being accepted and the application processing it? Therefore in this scenario the application-level - not the network-level - must acknowledge message receipt (when acknowledgements are used). > 2. There is an allowance for external acceptance notification > channels, though I admit this is not emphasized in the > text. Present in the base protocol are the Acceptance port type and > the agreement state resource property, both of which may be used > simultaneously on the same agreement. It is the state model which > allows for transitions to accepted state independent of the other > protocol operations. There is nothing to disallow other > notification paths such as email, facsimile, registered mail, etc. > (but, see next issue). > > 3. A significant difference between WS-Agreement and the contract law > model described in the paper is the moment of acceptance: in > WS-Agreement, acceptance is defined as the moment the responder > chooses to accept, and is not dependent on sending an acceptance > message to the initiator. This difference becomes clear in unusual > asynchronous/lossy message environments and/or contested > agreements. Yes, and since the publication of this paper we have learnt that this model of acceptance is also valid in contract law. It is called the 'mailbox rule' and (in a nutshell) says that as soon as the offeree 'posts' their acceptance the contract is made. Though it must be stated in advance that this is being used and not the traditional method we described in our paper. The protocol we are writing up uses the 'mailbox rule' model because (if the offeree was the service provider) it leads to the resources the contract is being made for being 'locked' - which I think we agree is an unacceptable situation - until the service provider knows the accept message has been received. > This is a crucial technical point in WS-Agreement. In order to > define the acceptance moment as when the acceptance is delivered to > the initiator (as in your contract law discussion) would require a > reliable delivery model where some trustworthy (third-party) > observer can witness the delivery. No, not necessarily. Note that business (generally) operates quite well without third-parties and often uses unreliable messaging to form contracts. There is also a well-known example (in legal circles, anyway) used to illustrate the loss of acceptance messages where the mailbox rule is not being applied, i.e. when acceptance is delivered to the offeror. It does not require a "reliable delivery model" or "a trustworthy observer" to be in place. The legal example, using the more correct terminology of 'offeror' and 'offeree' in place of initiator and responder, is as follows and should be understandable when applied to a distributed computing environment. The offeree shouts an acceptance message to the offeror. Just the offeree does so a plane passes overhead and the offeror does not hear the acceptance message (i.e. it is lost). The legal position is that it is upto the sender of the message to make sure the acceptance message gets through. Thus, the offeree keeps sending the message until they know it is understood. But, as you point out below, the offeror may choose to ignore (or claim not to receive) the accept message. However, because of the semantics of an offer, the offeror is bound to its contents if accepted so there is also an responsibility on the offeror to make sure they know the status of any offer that they make (and not make offers they do not intend to fulfil). The semantics of the message are critical in this protocol - hence my question to Dominic in my original email about the meaning of his 'offer' message. There are also other rules in contract law that help deal with this situation. The meaning of an offer (along with the experience gained over many years of forming contracts in distributed environments gathered by the legal community) makes the protocol inherent in contract law 'work': once an offer is made the offeror cannot walk away or choose not to take part if the offeree accepts that offer - even if they don't get the accept message. An offer is binding, unless it has been revoked. Therefore the offeror should always want to receive the accept so they can plan/reserve funds/do whatever they need to do - even if it is to ask that the contract is terminated immediately - as part of their side of the contract. If they don't then they will be at risk of breaking the contract and liable to the penalties therein. > At risk of confusing the terminology, a way to characterize such a > variant of our protocol might be: > > 1. initiator sends offer to responder. > > 2. responder chooses to accept. > > 3. responder attempts to send acceptance notice. > > 4. reliable message channel observes delivery of (3) and acceptance > is now true. > > Given our presumption of an Internet-like environment without any > secure, third-party channel to "serve" notices, this does nothing > more than "rotate" the participant roles by one unidirectional > message. In effect, it is really the "initiator" in step (4) who > decides acceptance by choosing to receive the acceptance notice or > not, because it is not possible to prove that he received a message > unless he acknowledges it! I agree, this is why we use the 'mail box' rule as otherwise we get into evidential issues about how many times the accept was attempted to be delivered, etc. But the offeror is still contracted whether they like it or not. > Thus, his offer is not really > obligating, as he can shirk his responsibilities by choosing not to > acknowledge the acceptance. About "his offer is not really obligating". How so? An offer is binding/obligating once made (again, unless revoked) therefore by "shirking their responsibilities" they may be breaking the contract and open to recourse. If it's not an offer then the offeree cannot accept it. The message must be an offer/not be an offer. It can't be a non-obligating offer, in that case it would be something else. > Thus, I would say the above "contract law"-style sequence of: > > offer/accept/receipt-as-decision > > is indistinguishable in practice from: > > invite/offer/accept-as-decision > > As there must be some party in the system that first knows the > decision before this information is distributed asynchronously to > all parties, we make the responder be the observer! Yes, contract law has an inherent bias towards the offeree who knows the decision first and is what (I think) you're saying. In a distributed system there will always be a lack of consistency somewhere (unless you sacrifice availability). A side question: what do you mean by "this information is distributed asynchronously to all parties". I thought WS-Agreement was 1:1 and the acceptance by the offeree only had to se sent (or made available) to the offeror? (i.e. one party). What "other parties" do you mean? > Finally, as I > described it in a previous email. WS-Agreement supports this > through the slightly more general: > > advertise/offer/accept-as-decision > > where you could restrict or otherwise optimize access to > advertisements in order to effect a directed invitation. (It is > considered somewhat out of scope for WS-Agreement to define how > advertisements are retrieved, e.g. what sort of publishing or > information dispersal architecture is used for discovery.) > > > I hope this helps clarify the technical solution embodied in > WS-Agreement. Thanks for taking the time to privide these clarifications. However they don't address the other question of the resource provider having to 'lock' it's resources in a 2PC-style when it makes an offer, as was also discussed (and a solution proposed) in our paper. Thanks again, Michael. From parkinm at cs.man.ac.uk Tue Aug 28 03:12:57 2007 From: parkinm at cs.man.ac.uk (parkinm at cs.man.ac.uk) Date: 28 Aug 2007 09:12:57 +0100 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: <46D30F1C.9070604@battre.de> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46D30F1C.9070604@battre.de> Message-ID: Hi Dominic, Just some quick questions: On Aug 27 2007, Dominic Battre wrote: > Thank you very much, Karl, for giving a lot of insight what is behind > WS-Agreement. > > > Furthermore, 2PC can be synthesized with two WS-Agreement round-trips > > and an appropriate domain-specific agreement semantics. So, either > > advance reservation, combined with the right cost/penalty model, or > > the underlying invitation system can both look like 2PC in practice: > > I tried to digest that and this is what I came up with: > > https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit Between step 5 and 6 of this protocol, how long does the provier wait for a response? As there is no facility for the user reject an offer in this protocol and let the provider know it doesn't want the advance reservation - the provider must specify a time limit to the offer, no? As was said in an earlier email - you can't assume agreement is going to happen... Also, what happens if between step 5 and 6 another user wants to reserve the same resources? What does the provider do then? As I mentioned in a previous email, the provider cannot offer those resources to the second user because if the first user accepts and the second user acccepts too, there is a problem of overcommitment of resources. > (I used my wiki because it supports tables) > > It would be great, if you could have a brief look at it and tell me > whether this is what you had in mind. > > > If some people want to contribute, I'd be interested in starting to > write a "Best Practices in WS-Agreement" / "Design Patterns in > WS-Agreement" / "WS-Agreement cookbook" / ... document. Yes, I am interested. > This issue of 2PC for example would be a good candidate for such a > document. I think it would really help if we find a place to collect > examples, approaches of modeling something, approaches of implementing > something, ... > > I could easily contribute lots of questions but maybe some answers as > well. Thanks, Michael. From parkinm at cs.man.ac.uk Tue Aug 28 03:17:16 2007 From: parkinm at cs.man.ac.uk (parkinm at cs.man.ac.uk) Date: 28 Aug 2007 09:17:16 +0100 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement In-Reply-To: References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46D30F1C.9070604@battre.de> Message-ID: Dominic, Sorry, I missed a step so I withdraw one of my questions below... On Aug 28 2007, parkinm at cs.man.ac.uk wrote: > On Aug 27 2007, Dominic Battre wrote: > > > Thank you very much, Karl, for giving a lot of insight what is behind > > WS-Agreement. > > > > > Furthermore, 2PC can be synthesized with two WS-Agreement round-trips > > > and an appropriate domain-specific agreement semantics. So, either > > > advance reservation, combined with the right cost/penalty model, or > > > the underlying invitation system can both look like 2PC in practice: > > > > I tried to digest that and this is what I came up with: > > > > https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit > > Between step 5 and 6 of this protocol, how long does the provier wait > for a response? As there is no facility for the user reject an offer in > this protocol and let the provider know it doesn't want the advance > reservation - the provider must specify a time limit to the offer, no? As > was said in an earlier email - you can't assume agreement is going to > happen... Sorry, please ignore this comment - I just saw the "User can cancel advance reservation offer for cheap fee" step. > Also, what happens if between step 5 and 6 another user wants to reserve > the same resources? What does the provider do then? > > As I mentioned in a previous email, the provider cannot offer those > resources to the second user because if the first user accepts and the > second user acccepts too, there is a problem of overcommitment of > resources. > > > > (I used my wiki because it supports tables) > > > > It would be great, if you could have a brief look at it and tell me > > whether this is what you had in mind. > > > > > > If some people want to contribute, I'd be interested in starting to > > write a "Best Practices in WS-Agreement" / "Design Patterns in > > WS-Agreement" / "WS-Agreement cookbook" / ... document. > > Yes, I am interested. > > > This issue of 2PC for example would be a good candidate for such a > > document. I think it would really help if we find a place to collect > > examples, approaches of modeling something, approaches of implementing > > something, ... > > > > I could easily contribute lots of questions but maybe some answers as > > well. > > Thanks, > > Michael. > From karlcz at univa.com Tue Aug 28 04:07:08 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 28 Aug 2007 16:07:08 +0700 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: References: <20070827065237.GG3276@crater.bbswl> Message-ID: <20070828090708.GK29479@crater.bbswl> On Aug 28, parkinm at cs.man.ac.uk modulated: > However, I don't think a message acknowledgement (in its most general > sense) is "a transport-level problem" (I'm not sure if you were agreeing or > disagreeing to this point and what your reference to SOAP/HTTP means - it > isn't clear). > There are multiple schools of thought on web service messaging, and I am not sure which school I belong to. :-) SOAP is a transport agnostic standard which has been conventionally applied with HTTP transport but could just as easily be mapped to SMTP, local procedure calls, a reliable message queueing system, or any other message-bearing infrastructure. It becomes murky because many of the arguments assume certain other software engineering practices in addition to the standards themselves. For example, there are those who want to separate the basic content-bearing messages, e.g. the abstract offer-accept protocol, from the implementation, e.g. offer-as-SOAP-over-HTTP or offer-as-SOAP-in-reliable-message-queue. There is nothing in the WSDL for a protocol which says that an in/out (RPC-style) message exchange has to occur in any particular amount of time. A year-long asynchronous offer-accept exchange could be represented in a single SOAP in/out message pair, if the transport bindings were chosen appropriately to allow reliable routing and processing of the messages. At the same time, the layers of abstraction are expected (by most people) to leak on occasion, e.g. the application becoming aware that a TCP/IP error prevented the SOAP-over-HTTP message delivery, or the reliable message queue taking responsibility for the message so the sender does not have to attempt retry etc. > For example, how do I know that a service didn't crash between the > transport-level message being accepted and the application processing it? > What difference would it make? :-) Is there some difference between crashing after the transport ACK or the application ACK? You seem to be assuming that the application is somehow more trustworthy than the transport to buffer/persist a message until application restart can make progress. This is an implementation choice that is not captured at all in the WSDL, but in the endpoint software stacks and the SOAP bindings that are in use... In any case, I am not advocating one view or the other, but trying to provide background on why the mixture of approaches has been defined in WS-Agreement. > > This is a crucial technical point in WS-Agreement. In order to > > define the acceptance moment as when the acceptance is delivered to > > the initiator (as in your contract law discussion) would require a > > reliable delivery model where some trustworthy (third-party) > > observer can witness the delivery. > > No, not necessarily. Note that business (generally) operates quite well > without third-parties and often uses unreliable messaging to form > contracts. There is also a well-known example (in legal circles, anyway) > used to illustrate the loss of acceptance messages where the mailbox rule > is not being applied, i.e. when acceptance is delivered to the offeror. It > does not require a "reliable delivery model" or "a trustworthy observer" to > be in place. > I think you are bringing in some of those intuitions I warned about... your legal example works because of a presumption of courts and evidential proof of due diligence etc. We could not readily assume such an environment for resolving WS-Agreement negotiations, since audit systems and legal systems are not within scope of the GRAAP-WG. We just toss up our hands and say one party is at the mercy of the other party sending notice of the decision. It becomes a separate quality of implementation or trust issue for offerors to choose offerees. This was important in order to provide a stepping stone for existing, traditional resource managers to be updated with WS-Agreement. The underlying offer/accept handshake and decision bias is very much consistent with conventional job-submission systems. We were also focused on relatively frequent (and automatic) real-time negotiation, i.e. the job and transient network QoS usage scenarios that motivated the GRAAP charter and its predecessors in the GARA and SNAP work. I think concerns about legal status and financial obligations took a back seat to concerns about practical distributed resource management. All the same, I think our solution MAY be applied soundly in an environment where more audit and legal rules are available to resolve conflicts in retrospect. We took pains to provide the runtime extensibility handling so that profiles/extensions could be defined for things such as digital signature of offers and acceptance messages (early public comments worried about getting digital signatures for non-repudiation, and we tried to enable this without making it mandatory for traditional Grid use cases). > I agree, this is why we use the 'mail box' rule as otherwise we get into > evidential issues about how many times the accept was attempted to be > delivered, etc. But the offeror is still contracted whether they like it or > not. > If the obligations can be contested based on "how many times the accept was attempted to be delivered, etc.", then what does it mean to say the offeror is "contracted"? (I ask this only out of academic interest, since you have already advocated the mail box rule.) > The message must be an offer/not be an offer. It can't be a non-obligating > offer, in that case it would be something else. > OK, I'll accept this tautology and rephrase my statement to say that there is a practical ambiguity in whether the message is an offer or not, if one is not using the mail box rule, due to the ability for the initiator to pretend not to receive the acceptance. > A side question: what do you mean by "this information is distributed > asynchronously to all parties". I was thinking of the co-allocation scenario where multiple SLAs are being formed with different providers. The initiator (in the advance reservation case) is acting as the coordinator to obtain multiple advance reservation SLAs (to prepare) and then obtaining matching claim SLAs (to commit) if he decides to go forward with the entire transaction. > Thanks for taking the time to privide these clarifications. However they > don't address the other question of the resource provider having to 'lock' > it's resources in a 2PC-style when it makes an offer, as was also discussed > (and a solution proposed) in our paper. > I am not sure I know what question or solution you mean here. All I see in my reading of the document is a statement that a resource provider should be the offeree to avoid live lock. Is this what you mean? WS-Agreement defines the initiator/responder roles (offeror and offeree as you say) and is silent on resource provider/consumer roles because these concepts are inherently domain-specific. However, in our example of a job system, we illustrate the use of JSDL-based terms for a client to make a job offer that the computing scheduler can accept or reject. This is our expected idiomatic application of WS-Agreement, which matches your preferred scenario. Your example in the document has a (to my eye) unusual scenario where a user "asks for a quote" and the computing service makes the offer. This is something we could have handled in SNAP via our invitation message, but the GRAAP-WG intentionally removed this capability. As I described in an earlier email, one could approximate this through a sophisticated use of advertisements (templates) and some template exchange system, but I think it is safe to say we marginalized this use case. Interestingly, we found that there are differences of opinion as to what the "resource" is in some concrete examples! It really depends on the domain, market, and community as to which aspect/role of the SLA is the more rare resource worth optimizing. If we assume that SLAs are about exchange of resource/service, the question is whether one party has a worse opportunity cost in obligating their resource in exchange for the other party's resource. If so, it would be preferable to allow the party with the worst opportunity cost to act as the offeree. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa Corp. and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address. From t-nakata at cw.jp.nec.com Tue Aug 28 20:25:57 2007 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 29 Aug 2007 10:25:57 +0900 Subject: [GRAAP-WG] Modification to the wiki Page on Renegotiatinganestablished Agreement In-Reply-To: <20070827025006.GD3276@crater.bbswl> References: <46B005B6.4010203@hp.com> <002201c7e498$3bfa74a0$b084380a@Sakurai> <46CC99F9.5030709@battre.de> <006101c7e51c$db95a190$b084380a@Sakurai> <46CD4458.3050101@battre.de> <003401c7e581$5f221700$b084380a@Sakurai> <46CD86CE.103@battre.de> <000801c7e589$c704f6a0$b084380a@Sakurai> <20070824095452.GA3811@granite.bbswl> <009e01c7e84d$0e0605b0$b084380a@Sakurai> <20070827025006.GD3276@crater.bbswl> Message-ID: <003901c7e9db$8cc9e620$b084380a@Sakurai> Karl: Thank you very much for your comments (and your patience in wating for my reply) The repli ----- Toshiyuki Nakata ?????? Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > > Toshi, I have the following comments/observations after reviewing your > wiki page... sorry I have not been able to keep a close watch on the > recent activities of the group. > > 1. The idea of negotiation of alternatives is difficult and I think > requires a better negotiation protocol. OK > > What I would suggest is that you try to keep this aspect of > negotiation protocol orthogonal to the underlying notion of > renegotiation. First, work on the semantics for renegotiation of > an agreement as you have done, e.g. replacement/superceding of an > agreement. Then, admit that basic or advanced protocols could be > used to negotiate either the initial or subsequent agreement. > I think this is fine as *much* discussion would have to be made for negotiation of alternatives. > > 2. I think the idea of superceding an agreement is fine, but I have > trouble seeing a distinction between this and the general use of > agreements in the context of other agreements. For example, the > advance reservation scenario allows "claiming" of a resource > reservation, and you can interpret this as adjusting an initial > resource agreement to include binding to an application, with the > same results as if someone simply negotiated an application with > the same QoS terms in one shot... > > What I would point out is that this claiming/context model allows > many:many derivation of agreements in the general case. E.g. I > could reserve a large resource (in space-time) and consume it with > multiple applications which either run serially or in parallel. I > could also combine several resources (in separate agreements) into > a complex application. Couldn't a renegotiation also be temporary, > e.g. "boost this resource reservation for the next hour, but then > fall back to the previous terms"? Your points are exactly what we had in mind in the business grid project.. (The scenarios are included in HPCC2006 paper http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0050.pdf I've also uploaded an excerpt from the presentation we made onto the Wiki. The last slide exactly shows the point I wanted to make.) > > I am not sure how "supercededby" would be applicable here. I think Supercededby could be useful for some purposes. eg. Logging purposes to show which Agreement had been effective until when then Superceded/replaced by which Agreement to check for SLA violation etc. > Is it > worth having one more general metalanguage for discovery/navigation > of agreements which are linked to other agreements? We could use > the extensibility of the wsag:Context to enumerate the actual > claimed or superseded agreements, I think this could be one way of realizing this feature. (I had intended to put the 'Superceded-by " in the wsag:Context) > and it seems useful to have a > dynamic resource property which could provide reverse-lookup of new > agreements which list an agreement in the new wsag:Context too. > > > 3. Also, a general concern I have is that the discussions are not > crisp about the uses of the agreement. The talk of race conditions > makes me nervous, as it seems to combine denotation of service > terms with the implementation of resource managers. In my view, > WS-Agreement is completely focused on the establishment of terms > between the two parties, and says nothing about how one of the > parties is implementing the protocol. I agree that this is a bit of an implementation issue but I think the discussion we had in Terminating was that Termination could take a long time to be decided and we extended the Agreement State wiht such states as ObservedAndTerminating so I had wanted to be consistent in this sense. ##As an off track issue, It seems in creating the official pdf, # http://www.ogf.org/documents/GFD.107.pdf Figure in Section 7.1 got corrupted.. Any way to remedy this? > > > 4. The question of having "responder initiated renegotiation" was > foreseen in the optional symmetric protocol mode. In essence, if > EPRs are exchanged so that both parties have an EPR representing > the other party's view of the agreement, then they can switch roles > and become initiator for further rounds of communication. In order > to use this feature, one would need to define an extension to the > protocol, e.g. have the symmetric agreement resources support an > extended protocol which includes the renegotiation operations as > well as the basic monitoring/cancellation operations. > > I think it would be appropriate to define a new negotiation > protocol as a profile on this feature, so that a specific SDT would > demand the presence of a renegotiation facility which would then be > available as extended operations and resource properties on the > Agreement resource. > > Again, if we consider the fuzzy case of many:many renegotiations, > the best approach might be a simple RP in the agreement that holds > an EPR to the renegotiation service, thereby separating discovery > (via lookup of this RP an existing agreement) from claiming/context > references which might involve more than one agreement at a time. > This is an interesting (if stagering) point. I had naively assumed that AR would be maintaining the Agreements A third party Agreement Factory could solve the problem with No.7 but this might have quite an impact on other parts of WS-Agreement Spec. Comments from other people also appreciated. Best Regards and Thanks Toshi > > karl > > > -- > Karl Czajkowski > Software Architect > > Univa Corporation > 1001 Warrenville Road, Suite 550 > Lisle, IL 60532 > > karlcz at univa.com > www.univa.com > ________________________________________________________________ > www.univa.com. > > The Leaders of Open Source Cluster and Grid Software > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070829/da6be532/attachment.bin From parkinm at cs.man.ac.uk Wed Aug 29 03:19:37 2007 From: parkinm at cs.man.ac.uk (parkinm at cs.man.ac.uk) Date: 29 Aug 2007 09:19:37 +0100 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: <20070828090708.GK29479@crater.bbswl> References: <20070827065237.GG3276@crater.bbswl> <20070828090708.GK29479@crater.bbswl> Message-ID: Hi Karl, On Aug 28 2007, Karl Czajkowski wrote: > > For example, how do I know that a service didn't crash between the > > transport-level message being accepted and the application processing > > it? > > What difference would it make? :-) Is there some difference between > crashing after the transport ACK or the application ACK? A lot and yes. A transport ack doesn't tell me the application recieved or was able to understand the content, for instance. > You seem to > be assuming that the application is somehow more trustworthy than the > transport to buffer/persist a message until application restart can > make progress. This is an implementation choice that is not captured > at all in the WSDL, but in the endpoint software stacks and the SOAP > bindings that are in use... What about server/container crashes? AFAIK TCP doesn't have a persistent buffer to protect against server crashes and most containers don't (natively) support message persistence unless you use a MOM. In this case, why not design the protocol so that it can handle these situations rather than specifying how it should be implemented? > > No, not necessarily. Note that business (generally) operates quite > > well without third-parties and often uses unreliable messaging to form > > contracts. There is also a well-known example (in legal circles, > > anyway) used to illustrate the loss of acceptance messages where the > > mailbox rule is not being applied, i.e. when acceptance is delivered to > > the offeror. It does not require a "reliable delivery model" or "a > > trustworthy observer" to be in place. > > I think you are bringing in some of those intuitions I warned > about... your legal example works because of a presumption of courts > and evidential proof of due diligence etc. WS-Agreement is going to be used where these institutions don't exist? Any resource provider (read business) potentially charging for work can't do this in splendid isolation of the existing local regulations and law... > We could not readily > assume such an environment for resolving WS-Agreement negotiations, > since audit systems and legal systems are not within scope of the > GRAAP-WG. I agree about the audit systems as this would be dependent on the local regulations where the service is being provided from. But, taking into account consideration the impact on business could be considered as being in scope if WS-Agreement is to be used between businesses (or individual users and businesses). One of the documents that got me interested in this topic was [1], where it states: "[agreements for Grid resources] present a formidable challenge, not least because of different international legal frameworks within which they have to operate" - others also recognise it can't be ignored. > We just toss up our hands and say one party is at the mercy > of the other party sending notice of the decision. As I've said before - the offeree always knows the decision before you. It isn't a question of throwing your hands up - this is how it is, therefore the offeror must be sure that they a prepared to enter into the contract when they make the offer. > It becomes a > separate quality of implementation or trust issue for offerors to > choose offerees. Of course, but how do you stop the bad guys? If there are no courts or we're outside the legal system (like you mentioned above) who's going to take care of them? > This was important in order to provide a stepping stone for existing, > traditional resource managers to be updated with WS-Agreement. The > underlying offer/accept handshake and decision bias is very much > consistent with conventional job-submission systems. We were also > focused on relatively frequent (and automatic) real-time negotiation, > i.e. the job and transient network QoS usage scenarios that motivated > the GRAAP charter and its predecessors in the GARA and SNAP work. I > think concerns about legal status and financial obligations took a > back seat to concerns about practical distributed resource management. As I said in another email, I believe that the legal, distributed computing and business aspects all need to be considered together. I also said that I think a simple protocol that meets these requirements is achievable. > All the same, I think our solution MAY be applied soundly in an > environment where more audit and legal rules are available to resolve > conflicts in retrospect. We took pains to provide the runtime > extensibility handling so that profiles/extensions could be defined > for things such as digital signature of offers and acceptance messages > (early public comments worried about getting digital signatures for > non-repudiation, and we tried to enable this without making it > mandatory for traditional Grid use cases). > > > I agree, this is why we use the 'mail box' rule as otherwise we get > > into evidential issues about how many times the accept was attempted to > > be delivered, etc. But the offeror is still contracted whether they > > like it or not. > > If the obligations can be contested based on "how many times the > accept was attempted to be delivered, etc.", then what does it mean to > say the offeror is "contracted"? (I ask this only out of academic > interest, since you have already advocated the mail box rule.) "What does it mean to say the offeror is contracted"? That they are bound to their obligations in the contract. I don't think the offeror would be contesting the obligations though, after all they sent them to the offeree. If they made a mistake and the offer was accepted - tough. (Like I said before, the offeror better be prepared to enter into a contract based on the offer they send). I presume that what you think may be contestable is whether the contract was actually formed or not if the agreement was never recieved. I think we've covered this. > OK, I'll accept this tautology and rephrase my statement to say that > there is a practical ambiguity in whether the message is an offer or > not, if one is not using the mail box rule, due to the ability for the > initiator to pretend not to receive the acceptance. If there's a 'practical ambiguity' between telling the difference between an offer and not-an-offer, then how do you tell the difference between any messages? If the message semantics/schema are defined and agreed to then you should be able to tell the difference and there is no practical ambiguity. If you haven't defined the semantics/schema (or have only partially defined them) then how can you interoperate at all? > > Thanks for taking the time to privide these clarifications. However > > they don't address the other question of the resource provider having > > to 'lock' it's resources in a 2PC-style when it makes an offer, as was > > also discussed (and a solution proposed) in our paper. > > I am not sure I know what question or solution you mean here. See the original discussion on 2PC being a blocking protocol. > All I see in my reading of the document is a statement that a resource > provider should be the offeree to avoid live lock. Is this what you > mean? Yes, the resource provider should always be the offeree to avoid locking its resources until it knows the other party is willing to make a contract for those resources. It avoids any possibility of a denial-of-service attack on the resource provider. > WS-Agreement defines the initiator/responder roles (offeror and > offeree as you say) and is silent on resource provider/consumer roles > because these concepts are inherently domain-specific. I don't agree - generally, this is domain-independent precisely because the supplier or provider won't want to commit their goods before they know they are being sold. It also gives them the opportunity to say 'no' in case they have made a mistake or want to offer them to someone else. I say generally, because this may happen but it's a marginal case. Can you give me some examples where the offeror is the supplier/provider? > Your example in the document has a (to my eye) unusual scenario where > a user "asks for a quote" and the computing service makes the offer. Our e-Challenges paper? If so, then this example ("computing service makes the offer") is used to illustrate why computing services shouldn't make offers - we weren't advocating it! Also, if "the computing service mak[ing] the offer" is an "unusual scenario", why does the protocol Dominic wrote up from your emails [2] describe this very situation? (Step 5). > This is something we could have handled in SNAP via our invitation > message, but the GRAAP-WG intentionally removed this capability. As I > described in an earlier email, one could approximate this through a > sophisticated use of advertisements (templates) and some template > exchange system, but I think it is safe to say we marginalized this > use case. I'm interested to know why this is a marginal use case for GRAAP-WG. I feel it is central in any agreement process in order for both parties to let the other know what they want/are providing without issuing any binding offers. I also believe it doesn't have to be "sophisticated" - eCommerce web sites (i.e. distributed Internet-based services selling finite resources) seem to do quite well with web pages. > Interestingly, we found that there are differences of opinion as to > what the "resource" is in some concrete examples! In my opinion a resource can be anything that can be traded. Time, money, a book, a house... > It really depends > on the domain, market, and community as to which aspect/role of the > SLA is the more rare resource worth optimizing. If we assume that > SLAs are about exchange of resource/service, the question is whether > one party has a worse opportunity cost in obligating their resource in > exchange for the other party's resource. If so, it would be > preferable to allow the party with the worst opportunity cost to act > as the offeree. Sorry, but what does "worst opportunity cost" mean? Please, in a couple of sentences :-) Michael. [1] ftp://ftp.cordis.lu/pub/ist/docs/grids/ngg3_eg_final.pdf [2] https://cit-server.cit.tu-berlin.de/trac/negmgr/wiki/TwoPhaseCommit From karlcz at univa.com Wed Aug 29 04:44:05 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 29 Aug 2007 16:44:05 +0700 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: References: <20070827065237.GG3276@crater.bbswl> <20070828090708.GK29479@crater.bbswl> Message-ID: <20070829094405.GF12708@crater.bbswl> On Aug 29, parkinm at cs.man.ac.uk modulated: > WS-Agreement is going to be used where these institutions don't exist? Any > resource provider (read business) potentially charging for work can't do > this in splendid isolation of the existing local regulations and law... > My point was rather that we expect these audit and legal issues to be "mixed in" by a community that deploys WS-Agreement for a particular purpose. I think we've talked around in circles but more or less observe that the underlying semantics of WS-Agreement are consistent with typical legal contracting environments. It may not be complete, but that is because we did not have the charter to try to standardize all aspects of discovery, security, audit, nor domain-specific SLA terminology. > I presume that what you think may be contestable is whether the contract > was actually formed or not if the agreement was never recieved. I think > we've covered this. > Yes, and yes. We're close to counting angels on pins, I'm afraid... > If the message semantics/schema are defined and agreed to then you should > be able to tell the difference and there is no practical ambiguity. If you > haven't defined the semantics/schema (or have only partially defined them) > then how can you interoperate at all? > I think the WS-Agreement decision semantics are clear, but what the terms of the SLA actually mean and how these terms bind the two parties is necessarily domain dependent. Maybe my philosophy is too strange for you, but I have trouble defining obligations and trust in the absence of these domain-dependent concepts. Keeping my spec-authoring hat on, I have to remind myself that I do not know how strongly or weakly the domain-specific terms will capture obligations between parties when someone applies WS-Agreement in practice. > >WS-Agreement defines the initiator/responder roles (offeror and > >offeree as you say) and is silent on resource provider/consumer roles > >because these concepts are inherently domain-specific. > > I don't agree - generally, this is domain-independent precisely because the > supplier or provider won't want to commit their goods before they know they > are being sold. It also gives them the opportunity to say 'no' in case they > have made a mistake or want to offer them to someone else. I say generally, > because this may happen but it's a marginal case. Can you give me some > examples where the offeror is the supplier/provider? > The very concept of "supplier" and "goods" is necessarily domain dependent. Therefore, WS-Agreement cannot make normative statements about this since it does not actually define any normative terms for any actual application domain. That was the general thinking in the working group after this topic was debated before... > Also, if "the computing service mak[ing] the offer" is an "unusual > scenario", why does the protocol Dominic wrote up from your emails [2] > describe this very situation? (Step 5). > Because it was an "unusual" interpretation of what I wrote, i.e. I would say that this step is completely backwards from what I described in my email. Did my reply to Dominic and the graap-wg list not go through? I thought I already pointed out that it was backwards, and repeated the idiomatic advance-reservation solution for 2PC which has the coordinator acting as initiator to both agreements with the resource provider. > >This is something we could have handled in SNAP via our invitation > >message, but the GRAAP-WG intentionally removed this capability. As I > >described in an earlier email, one could approximate this through a > >sophisticated use of advertisements (templates) and some template > >exchange system, but I think it is safe to say we marginalized this > >use case. > > I'm interested to know why this is a marginal use case for GRAAP-WG. I feel > it is central in any agreement process in order for both parties to let the > other know what they want/are providing without issuing any binding offers. > To illustrate the underlying WS-Agreement model and roles, it is for a responder to be equipped to receive and consider binding offers, and to shout from the rooftops: here are my templates, please give me offers! And it is for the initiator to somehow (not specified in WS-Agreement) hear these shouted templates, choose among them, formulate an offer, and contact the responder to initiate the protocol. What was marginalized in WS-Agreement was the idea of a customized or multi-round advertisement. It was considered sufficient (for now) to publish advertisements unilaterally, and formulate offers in response to these advertisements. If you want to allow either party to initiate, then the WS-Agreement solution would be for all parties to publish their templates as responders, and for all parties to choose wisely when they would like to become an initiator and make an offer. If you want custom tailored advertisements that take into account your own interests, then you need something more sophisticated. Either an elaborate brokerage/search facility to locate templates or an explicit multi-round discovery protocol. Both of these were set explicitly out of scope for the first version of WS-Agreement. > Sorry, but what does "worst opportunity cost" mean? Please, in a couple of > sentences :-) > > Michael. > Well, would we agree with this layman's definition of opportunity cost: the lost benefit associated with "locking" a resource and taking it out of play? If so, then the "worst" one is the one that has a higher cost in some global value system! Your judgement about wanting resource providers to be the offeree to avoid live-lock comes from a global view of the system, where you've placed value on the opportunity cost for both parties. E.g., if we stick to the computing environment scenario: the consumer who ties up his "computational units" and the provider who ties up his "computation resources". Then, you've made a judgement that the tying up of resources is a worse outcome than the tying up of the units, presumably because you expect the resources to be scarce or utilization to be the most important metric. This relative evaluation is deeply mired in your assumptions about what the resources are and what it costs the system (society, whatever) to have them tied up. Might there not be a community where the resource providers are hungry for customers and would gladly act as offerors to bid for the right to execute their applications? That possibility is at the heart of our decision to remain silent and allow domain-specific profiles of WS-Agreement to choose how best to apply the protocol. I personally think that this decision should be allowed at runtime, because even within a particular application domain, different participants may have different risk and benefit assessments. In fact, these assessments may vary depending on who they are dealing with. A fully symmetric deployment of WS-Agreement would allow this. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa Corp. and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address. From parkinm at cs.man.ac.uk Thu Aug 30 02:59:39 2007 From: parkinm at cs.man.ac.uk (Michael Parkin) Date: Thu, 30 Aug 2007 09:59:39 +0200 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: <20070829094405.GF12708@crater.bbswl> References: <20070827065237.GG3276@crater.bbswl> <20070828090708.GK29479@crater.bbswl> <20070829094405.GF12708@crater.bbswl> Message-ID: <1E21D494-9DC9-4BED-9BCA-02756FCEC501@cs.man.ac.uk> Hi Karl, On 29 Aug 2007, at 11:44, Karl Czajkowski wrote: > My point was rather that we expect these audit and legal issues to be > "mixed in" by a community that deploys WS-Agreement for a particular > purpose. I think we've talked around in circles but more or less > observe that the underlying semantics of WS-Agreement are consistent > with typical legal contracting environments. It may not be complete, > but that is because we did not have the charter to try to standardize > all aspects of discovery, security, audit, nor domain-specific SLA > terminology My point is that how do you know they can be "mixed in" successfully if they haven't been considered beforehand? >> If the message semantics/schema are defined and agreed to then you >> should >> be able to tell the difference and there is no practical >> ambiguity. If you >> haven't defined the semantics/schema (or have only partially >> defined them) >> then how can you interoperate at all? > > I think the WS-Agreement decision semantics are clear, but what the > terms of the SLA actually mean and how these terms bind the two > parties is necessarily domain dependent. Maybe my philosophy is too > strange for you, but I have trouble defining obligations and trust in > the absence of these domain-dependent concepts. Keeping my > spec-authoring hat on, I have to remind myself that I do not know how > strongly or weakly the domain-specific terms will capture obligations > between parties when someone applies WS-Agreement in practice. With respect, we were talking generally, not specifically about WS- Agreement. I have no doubt the "decision semantics" in WS-Agreement are clear. I was making a general point because you said there were "practical ambiguities" in determining the differences between messages, which we both agree do not exist if the message schema and semantics are agreed to beforehand... About obligations and trust, I agree this is something we cannot solve completely here. But cross-administrative domain contracts in the presence of the threat of enforcement (legally) can help build trust between distrustful parties - therefore it is imperative any agreement/negotiation protocol is consistent with these requirements. >> I don't agree - generally, this is domain-independent precisely >> because the >> supplier or provider won't want to commit their goods before they >> know they >> are being sold. It also gives them the opportunity to say 'no' in >> case they >> have made a mistake or want to offer them to someone else. I say >> generally, >> because this may happen but it's a marginal case. Can you give me >> some >> examples where the offeror is the supplier/provider? > > The very concept of "supplier" and "goods" is necessarily domain > dependent. Sorry, I still don't agree. The fact you can use the words "supplier" and "goods" without talking about what you're supplying or which goods you're referring to illustrates they are abstract, domain- independent concepts... I'll also ask my question again: can you give me some real-world examples where the offeror is the supplier/provider of goods? :-) >> Also, if "the computing service mak[ing] the offer" is an "unusual >> scenario", why does the protocol Dominic wrote up from your emails >> [2] >> describe this very situation? (Step 5). > > Because it was an "unusual" interpretation of what I wrote, i.e. I > would say that this step is completely backwards from what I described > in my email. Did my reply to Dominic and the graap-wg list not go > through? Sorry, but there was no mention in your correspondence to Dominic that the protocol was an "unusual interpretation" of those emails. It doesn't say anything about you feeling step 5 was "completely backwards", though I agree your revised protocol does reverse the offer step. Thanks for clearing this up. > I thought I already pointed out that it was backwards, and > repeated the idiomatic advance-reservation solution for 2PC which has > the coordinator acting as initiator to both agreements with the > resource provider. Great! If step 5 is "backwards" we're agreed that the resource provider/supplier shouldn't make offers then? > If you want to allow either party to initiate, then the WS-Agreement > solution would be for all parties to publish their templates as > responders, and for all parties to choose wisely when they would like > to become an initiator and make an offer. Yes, precisely my point from my last email - the offeror needs to take care. A wise provider/supplier should, therefore, always choose to be the offeree - the point we made in our paper. > If you want custom tailored advertisements that take into account your > own interests, then you need something more sophisticated. Either an > elaborate brokerage/search facility to locate templates or an explicit > multi-round discovery protocol. Both of these were set explicitly out > of scope for the first version of WS-Agreement. I agree that the provision of "tailored advertisements", or quotes, are something else to the general adverts you mention above (although there is no difference in law - they are both 'invites to treat'). But, I don't think this provision has to be "elaborate" or "sophisticated". As I said in a previous email, eCommerce websites, such as flight brokering firms, seem to have no problem providing this. > Your judgement about wanting resource providers to be the offeree to > avoid live-lock comes from a global view of the system, where you've > placed value on the opportunity cost for both parties. E.g., if we > stick to the computing environment scenario: the consumer who ties up > his "computational units" and the provider who ties up his > "computation resources". Then, you've made a judgement that the tying > up of resources is a worse outcome than the tying up of the units, > presumably because you expect the resources to be scarce or > utilization to be the most important metric. As we said in the eChallenges paper, taking into account the wider picture, ensuring that (in this case) computational resources are not "tied up" is fairer for all customers too; no single customers can block other customers from making a definite offer on a particular resource unless they are committed to using the service by offering to enter into a binding contract for those resources. > This relative evaluation is deeply mired in your assumptions about > what the resources are and what it costs the system (society, > whatever) to have them tied up. If you are referring to the eChallenges paper, then we used computational resource provision as an example because of the audience and conference it was intended for. Because we used this example it does not mean our/my general assumptions are "deeply mired" as to what the resources or goods are, as I hinted at in the 'domain-independent' comment above. From the example resources I gave in my last email (time, money, a book, a house... anything that can be traded) and my comments in previous emails I hoped this was clear, but obviously it wasn't... > Might there not be a community where > the resource providers are hungry for customers and would gladly act > as offerors to bid for the right to execute their applications? If these resource providers are "hungry for customers" it may mean they are unattractive or unknown to their potential customers. In the real-world a business would, for example, lower their prices, advertise to raise their profile, provide special discounts, etc. to attract customers. However, they still don't make binding offers - and by doing so they get the benefits of protecting themselves from making offers they cannot fulfil (i.e. mistakes), not having to commit goods until a customer has sent them a binding offer, and protection from denial of service possibilities that would leave them with even less income (as they can offer what they are selling for a higher price whilst another customer makes up their mind - again, allowing them to maximise revenue). As I mentioned above, their customers also get the benefits of knowing that other customers can't block them from making an offer on any goods or services too. Can you provide an example of where resource providers/suppiers would "gladly act as offerors"? :-) Thanks, Michael. From karlcz at univa.com Thu Aug 30 04:05:28 2007 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 30 Aug 2007 16:05:28 +0700 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: <1E21D494-9DC9-4BED-9BCA-02756FCEC501@cs.man.ac.uk> References: <20070827065237.GG3276@crater.bbswl> <20070828090708.GK29479@crater.bbswl> <20070829094405.GF12708@crater.bbswl> <1E21D494-9DC9-4BED-9BCA-02756FCEC501@cs.man.ac.uk> Message-ID: <20070830090528.GJ24586@crater.bbswl> On Aug 30, Michael Parkin modulated: > Hi Karl, > > My point is that how do you know they can be "mixed in" successfully > if they haven't been considered beforehand? > Well, many possible scenarios were considered beforehand, and that is partly why WS-Agreement took such a long, slow stroll from charter to proposed standard... but once considered, they were not written into the specification since our considerations had no normative weight. I fear that I am losing track of this discussion, which I entered with the sole purpose of trying to clarify expected WS-Agreement usage scenarios. What I want to make clear out of all these discussions is that I think it would be unwise for GRAAP-WG to charter any work on a different transactional decision protocol, given both that the two-cycle reserve/claim idiom was central to the definition of the current proposed standard and that the single-cycle offer/accept risks are unavoidable in any distributed system. Similarly, I assert that it would be unwise to define some sort of multi-step obligating negotiation, as this is best modeled through chained agreements to compose/revise incremental obligations. This captures the actual sequence points of any multi-round obligation including who is obligated and what risks there are due to distributed system faults etc. On the other hand, I think it is clear that there is a need for a "WS-Agreement Primer", something that has been on the back burner in GRAAP-WG since the very early specification drafts, as decisions were made to intentionally avoid polluting the spec with too many tangential discussions. There is also a need for one or more new protocols to capture the different goals people have raised such as "tailored advertisements" and "renegotiation". > With respect, we were talking generally, not specifically about WS- > Agreement. I have no doubt the "decision semantics" in WS-Agreement > are clear. I was making a general point because you said there were > "practical ambiguities" in determining the differences between > messages, which we both agree do not exist if the message schema and > semantics are agreed to beforehand... > No wonder the confusion---I was talking specifically about WS-Agreement and its motivations... I fear that I am already muddying the waters here in a way that is not helpful to the general GRAAP-WG discussions about how to actually use WS-Agreement or how to consider sensible extensions/complements to the current proposed standard. (The topic of the semantics of a message between untrusted participants is more of a philosophical discussion, best had over beers or your own beverage of choice). > About obligations and trust, I agree this is something we cannot > solve completely here. But cross-administrative domain contracts in > the presence of the threat of enforcement (legally) can help build > trust between distrustful parties - therefore it is imperative any > agreement/negotiation protocol is consistent with these requirements. > Is there something about WS-Agreement which you think is inconsistent as such? I am not able to see this now through the confusingly threaded discussion... please, if you would, start new threads with specific inconsistencies or problems you see in the protocol? To my knowledge, none of the regular GRAAP-WG participants who contributed to WS-Agreement were legal/contract experts. We steered clear of things like digital signature in the basic specification partly because we got answers from outside experts that it was best left to localization/composition with other standards. However, I felt that the basic business-to-business scenarios were well represented by the commercial participants. > >The very concept of "supplier" and "goods" is necessarily domain > >dependent. > > Sorry, I still don't agree. The fact you can use the words "supplier" > and "goods" without talking about what you're supplying or which > goods you're referring to illustrates they are abstract, domain- > independent concepts... > After all the years spent developing the WS-Agreement specification, I personally can no longer use the words "supplier" and "goods" without qualification. :-) I consider agreements rather to be _trades_ and the identification of goods or direction of a provider-consumer relationship to be in the eye of the beholder. In fact, the general case is probably that both parties are both provider and consumer, and your question boils down to "how much?" are they doing of each. > I'll also ask my question again: can you give me some real-world > examples where the offeror is the supplier/provider of goods? :-) > No, but I can give examples where the role is not clear. Consider bandwidth trading, whether in ISP peering relationships or in some dynamically negotiated p2p network. The unit of commodity provided by both parties is equivalent, yet someone needs to be the offeror. I think there are plenty of other examples where the trades are not equal but they are still not as glaringly different as "product" for "money". The choice of roles is more contextually dependent here, getting back to the relative opportunity costs of negotiation which I mentioned previously. The WS-Agreement model was written to remain agnostic on this point, not because we want to encourage "unwise" choice of offeror/offeree roles, but because we could not rule on all possible future applications of the protocol. Anything we wrote would end up being non-normative, so again it was deferred as a topic for "the primer". > Sorry, but there was no mention in your correspondence to Dominic > that the protocol was an "unusual interpretation" of those emails. It > doesn't say anything about you feeling step 5 was "completely > backwards", though I agree your revised protocol does reverse the > offer step. Thanks for clearing this up. > Ah, sorry, I thought I had made that more clear. However, let me point out that though a computer provider would be the offeree in both the advance reservation and the job submission agreements in my idiomatic reservation example, it is in effect the offeror for the actual resource consumption decision that is synthesized from these two agreements. The client/consumer is getting an offer of resources in the accepted agreement and choosing to accept or reject by either submitting his claiming agreement (to run the job) or canceling the reservation. > But, I don't think this provision has to be "elaborate" or > "sophisticated". As I said in a previous email, eCommerce websites, > such as flight brokering firms, seem to have no problem providing this. > These interfaces are elaborate, as compared to WS-Agreement in two significant ways: 1. Some of them require human intelligence in one party, whether to construct the request, formulate a query, or filter through "fuzzy" results. This is not acceptable for WS-Agreement which has among its intended audiences machine-to-machine negotiation for resource management. 2. They have domain-specific data models and query models to allow appropriate parameterization of the quote-retrieval step. I don't think there is anyone offering up a generic/domain neutral data model and query model that would be sufficiently complete so as to provide real interop. Even the template mechanism in WS-Agreement is arguably incomplete and requires domain-specialization to support real automated negotiation. > As we said in the eChallenges paper, taking into account the wider > picture, ensuring that (in this case) computational resources are not > "tied up" is fairer for all customers too; no single customers can > block other customers from making a definite offer on a particular > resource unless they are committed to using the service by offering > to enter into a binding contract for those resources. > This sort of argument, however, has often been used in the past to discourage advance reservation in any form. To turn it around, resource providers MAY choose to reduce utilization if they feel that offering timeliness of service via reservation is a good trade-off to improve the utility (or profitability) of their systems. The trick is having appropriate costs for negotiation, so that the "tied up" resources are still profitable. Looking to real world examples, it typically costs me more to reserve a hotel and be a "no show" on the date of arrival than to reserve and then cancel months before my expected visit. It might not serve society if nobody could book rooms in advance and form sane itineraries... yet this is the state of practice in most of the HPC computing space. :-) > Because we used this example it does not mean our/my general > assumptions are "deeply mired" as to what the resources or goods are, > as I hinted at in the 'domain-independent' comment above. From the > example resources I gave in my last email (time, money, a book, a > house... anything that can be traded) and my comments in previous > emails I hoped this was clear, but obviously it wasn't... > I am reading between the lines here, but I suspect that you are focusing on "money for goods" trades. Otherwise, I think you would agree that the proper bias for the "offeror risk" is not so clear in a general multiple party (many:many) "goods for goods" trading market. Once the units of trade are less disjoint in terms of being available or fungible, I struggle to see an obvious choice of roles. I think it has to be made on a case by case basis. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software From parkinm at cs.man.ac.uk Fri Aug 31 04:30:50 2007 From: parkinm at cs.man.ac.uk (parkinm at cs.man.ac.uk) Date: 31 Aug 2007 10:30:50 +0100 Subject: [GRAAP-WG] Feedback on "Challenges in EU Grid Contracts" In-Reply-To: <20070830090528.GJ24586@crater.bbswl> References: <20070827065237.GG3276@crater.bbswl> <20070828090708.GK29479@crater.bbswl> <20070829094405.GF12708@crater.bbswl> <1E21D494-9DC9-4BED-9BCA-02756FCEC501@cs.man.ac.uk> <20070830090528.GJ24586@crater.bbswl> Message-ID: Hi Karl, On Aug 30 2007, Karl Czajkowski wrote: > I fear that I am losing track of this discussion, which I entered with > the sole purpose of trying to clarify expected WS-Agreement usage > scenarios. I thought this discussion was/is regarding your feedback on our paper "Challenges in EU Grid Contracts" (see title of thread) in which we asserted that resource providers should not make binding offers, amongst other things. Therefore, I have tried to relate your comments, where possible, to the points we made in that paper. For your benefit I have limited my comments in this email to a couple of things. Limiting my comments does not imply with I agree with everything in your last email (just as in contract law, silence is not an indication of acceptance) but I feel you want to start wrapping this up. > > With respect, we were talking generally, not specifically about WS- > > Agreement. I have no doubt the "decision semantics" in WS-Agreement > > are clear. I was making a general point because you said there were > > "practical ambiguities" in determining the differences between > > messages, which we both agree do not exist if the message schema and > > semantics are agreed to beforehand... > > No wonder the confusion---I was talking specifically about > WS-Agreement and its motivations... I fear that I am already muddying > the waters here in a way that is not helpful to the general GRAAP-WG > discussions about how to actually use WS-Agreement or how to consider > sensible extensions/complements to the current proposed standard. > (The topic of the semantics of a message between untrusted > participants is more of a philosophical discussion, best had over > beers or your own beverage of choice). Sure, if you're ever in Barcelona give me a shout. > Is there something about WS-Agreement which you think is inconsistent > as such? I am not able to see this now through the confusingly > threaded discussion... please, if you would, start new threads with > specific inconsistencies or problems you see in the protocol? I don't know (because the WS-Agreement specification is complicated and the protocol mixed in with implementation details), and of course. > > I'll also ask my question again: can you give me some real-world > > examples where the offeror is the supplier/provider of goods? :-) > > No, but I can give examples where the role is not clear. Consider > bandwidth trading, whether in ISP peering relationships or in some > dynamically negotiated p2p network. The unit of commodity provided by > both parties is equivalent, yet someone needs to be the offeror. I > think there are plenty of other examples where the trades are not > equal but they are still not as glaringly different as "product" for > "money". The choice of roles is more contextually dependent here, > getting back to the relative opportunity costs of negotiation which I > mentioned previously. Yes, the choice of roles is "contextually dependent", but the provider will always be the offeree. > However, let me point out that though a computer provider would be the > offeree in both the advance reservation and the job submission > agreements in my idiomatic reservation example, it is in effect the > offeror for the actual resource consumption decision that is > synthesized from these two agreements. The client/consumer is getting > an offer of resources in the accepted agreement and choosing to accept > or reject by either submitting his claiming agreement (to run the job) > or canceling the reservation. Sorry, but is this protocol written up and in the GRAAP-WG documents? If so, please could you tell me where and I will comment on it in another thread. > > But, I don't think this provision has to be "elaborate" or > > "sophisticated". As I said in a previous email, eCommerce websites, > > such as flight brokering firms, seem to have no problem providing this. > > These interfaces are elaborate, as compared to WS-Agreement in two > significant ways: > > 1. Some of them require human intelligence in one party, whether to > construct the request, formulate a query, or filter through "fuzzy" > results. This is not acceptable for WS-Agreement which has among > its intended audiences machine-to-machine negotiation for resource > management. > > 2. They have domain-specific data models and query models to allow > appropriate parameterization of the quote-retrieval step. > > I don't think there is anyone offering up a generic/domain neutral > data model and query model that would be sufficiently complete so as > to provide real interop. Even the template mechanism in WS-Agreement > is arguably incomplete and requires domain-specialization to support > real automated negotiation. Apologies. Regarding this point, I was referring to the protocols (i.e. semantics and allowed sequence of messages) they use, not the interfaces, message content or strategy (all of which are orthogonal to the protocol). Sorry if this was not clear to you. > > As we said in the eChallenges paper, taking into account the wider > > picture, ensuring that (in this case) computational resources are not > > "tied up" is fairer for all customers too; no single customers can > > block other customers from making a definite offer on a particular > > resource unless they are committed to using the service by offering > > to enter into a binding contract for those resources. > > This sort of argument, however, has often been used in the past to > discourage advance reservation in any form. I know you're getting tired of this thread - and this is my last question - but can you explain how can this point be used to "discourage advance reservation in any form"? > To turn it around, > resource providers MAY choose to reduce utilization if they feel that > offering timeliness of service via reservation is a good trade-off to > improve the utility (or profitability) of their systems. If they can be more profitable or "improve the utility of their systems" by doing less, for example, then this is ok with me - the operating model of the provider has little to do with the protocol used to create the agreements, which is the same regardless of the internal strategy of the provider/supplier. > The trick is having appropriate costs for negotiation, so that the > "tied up" resources are still profitable. Looking to real world > examples, it typically costs me more to reserve a hotel and be a "no > show" on the date of arrival than to reserve and then cancel months > before my expected visit. It might not serve society if nobody could > book rooms in advance and form sane itineraries... yet this is the > state of practice in most of the HPC computing space. :-) Again, costs and profitability are a message content/internal strategy issue, which has little to do with the protocol used to create the agreements. Whether I book a room in the New York Hilton or a 1* pension here, the protocol is the same and the hotel is always the offeree. What they charge me in booking or cancellation fees depends on what each provider (of hotel rooms in this case) inserts into their part of the contract during the agreement process. > > Because we used this example it does not mean our/my general > > assumptions are "deeply mired" as to what the resources or goods are, > > as I hinted at in the 'domain-independent' comment above. From the > > example resources I gave in my last email (time, money, a book, a > > house... anything that can be traded) and my comments in previous > > emails I hoped this was clear, but obviously it wasn't... > > I am reading between the lines here, but I suspect that you are > focusing on "money for goods" trades. Then you have read "between the lines" incorrectly. I am not focussed on "money for goods" trades. As I said in the last email I?m interested in resources that can be traded - this does not mean they are always traded for money. > Otherwise, I think you would > agree that the proper bias for the "offeror risk" is not so clear in a > general multiple party (many:many) "goods for goods" trading market. > Once the units of trade are less disjoint in terms of being available > or fungible, I struggle to see an obvious choice of roles. I think it > has to be made on a case by case basis. The provider will always choose to be the offeree because of the reasons I explained in my previous emails. If you want me to go through them again, please say so. :-) Thanks, Michael.