February 2008 - graap-wg

FW: Re-negotiation Protocol Proposal
by Toshiyuki Nakata 04 Mar '08

04 Mar '08

Hi Karl: > > Apparently, you want to consider the original agreement responder as a > "server side" component, so you don't feel complete until the original > initiator holds an EPR to an agreement representing the renegotiation > back on this "server side". Am I correct? > > I would not say that the agreement responder would be on the "Server" side. I had just assumed that the agreement factory would be on the Agreement responder side. > > A better rendering might eliminate this round-trip. What you could do > is send a PendingAgreement EPR in the initial renegotiation offer, so > the renegotiation responder already has an EPR before he decides to > accept. This would also support the Accept message, so the responder > could simply invoke that and be done with it. > WOuld this be same for both the cases of MI=AI and MI=AR? We were discussing in the group about the appplicability of having a modified EPR for MI=AR case... 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@univaud.com] > Sent: Friday, February 29, 2008 5:16 PM > To: Toshiyuki Nakata > Subject: Re: [GRAAP-WG] Re-negotiation Protocol Proposal > > On Feb 29, Toshiyuki Nakata modulated: > > > Hi Karl: we had three interesting sessions today. > > For the preparation of the sessions I created (today ;-) > > Some slides trying to see the roles. > > In pages 6-7 I tried to depict my interpretation of your comments. > > Please see if they are wrong or right. > > a)If wrong: Please tell me where I'd gone wron (and a > picture would help > > :-))) > > b)If OK please give us comments on my question in slide 7. > > ie. How can ADF verify thatAR agreed to the modification? > > > > I wouldn't say slide 7 captures my comment. My endpoint rendering > doesn't imply a third entity, just that the responder entity is > rendered with multiple endpoints to allow a more general scenario such > as renegotiation that could combine multiple agreements (something you > couldn't do if the preceding agreement is always implied like the > "this" pointer in a simple object system): > > 1. agreement initiator sends offer to agreement factory > > 2. agreement factory sends accept (sync or async reply) > > ... repeat 1-2 for multiple agreements... > > 3. renegotiation initiator sends offer to agreement factory > > 4. agreement factory sends accept (sync or async reply) > > in step (3) the renegotiation offer includes a reference to the > initial agreement(s) and the responder needs to validate that it makes > sense, e.g. that the right parties are involved and that the terms > would meaningfully supercede all of the referenced agreements. > > I would also disagree with your reversed roles being a 2-phase > decision protocol. The fact that you have an extra round-trip to find > the agreement EPR is an artifact of your rendering. Due to the nature > of the obligation assumed by the offerer when he sent the offer, he > doesn't have the right to refuse to give you the agreement when you > decide to accept. Having this fail is no different than any other > communication or implementation fault; it can happen in the real > world, but it is clear that the contract is binding anyway if the > responder got an offer and "sent an accept" based on the post-box rule > mentioned in the renegotiation proposal paper. > > Apparently, you want to consider the original agreement responder as a > "server side" component, so you don't feel complete until the original > initiator holds an EPR to an agreement representing the renegotiation > back on this "server side". Am I correct? > > A better rendering might eliminate this round-trip. What you could do > is send a PendingAgreement EPR in the initial renegotiation offer, so > the renegotiation responder already has an EPR before he decides to > accept. This would also support the Accept message, so the responder > could simply invoke that and be done with it. > > This same thing would apply in any symmettric peer-to-peer scenario as > well, just as with the existing WS-Agreement mechanism. By > maintaining Agreement and RenegotiatedAgreement resources "on both > sides", we can see the decoupled state of the negotiations from each > party's perspective. > > > karl > > -- > Karl Czajkowski > Software Architect > > Univa UD > 1001 Warrenville Road, Suite 550 > Lisle, IL 60532 > > karlcz(a)univaud.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 UD 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.

3 2

Re: [GRAAP-WG] Re-negotiation Protocol Proposal
by Karl Czajkowski 01 Mar '08

01 Mar '08

[This started as a private message but Toshi and I realized we should put the discussion on the list...] On Feb 29, Toshiyuki Nakata modulated: > Hi Karl: we had three interesting sessions today. > For the preparation of the sessions I created (today ;-) > Some slides trying to see the roles. > In pages 6-7 I tried to depict my interpretation of your comments. > Please see if they are wrong or right. > a)If wrong: Please tell me where I'd gone wron (and a picture would help > :-))) > b)If OK please give us comments on my question in slide 7. > ie. How can ADF verify thatAR agreed to the modification? > I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system): 1. agreement initiator sends offer to agreement factory 2. agreement factory sends accept (sync or async reply) ... repeat 1-2 for multiple agreements... 3. renegotiation initiator sends offer to agreement factory 4. agreement factory sends accept (sync or async reply) in step (3) the renegotiation offer includes a reference to the initial agreement(s) and the responder needs to validate that it makes sense, e.g. that the right parties are involved and that the terms would meaningfully supercede all of the referenced agreements. I would also disagree with your reversed roles being a 2-phase decision protocol. The fact that you have an extra round-trip to find the agreement EPR is an artifact of your rendering. Due to the nature of the obligation assumed by the offerer when he sent the offer, he doesn't have the right to refuse to give you the agreement when you decide to accept. Having this fail is no different than any other communication or implementation fault; it can happen in the real world, but it is clear that the contract is binding anyway if the responder got an offer and "sent an accept" based on the post-box rule mentioned in the renegotiation proposal paper. Apparently, you want to consider the original agreement responder as a "server side" component, so you don't feel complete until the original initiator holds an EPR to an agreement representing the renegotiation back on this "server side". Am I correct? A better rendering might eliminate this round-trip. What you could do is send a PendingAgreement EPR in the initial renegotiation offer, so the renegotiation responder already has an EPR before he decides to accept. This would also support the Accept message, so the responder could simply invoke that and be done with it. This same thing would apply in any symmettric peer-to-peer scenario as well, just as with the existing WS-Agreement mechanism. By maintaining Agreement and RenegotiatedAgreement resources "on both sides", we can see the decoupled state of the negotiations from each party's perspective. karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz(a)univaud.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 UD 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.

3 5

Re: [GRAAP-WG] Re-negotiation Protocol Proposal
by Karl Czajkowski 25 Feb '08

25 Feb '08

[Sorry, this bounced the first time I tried to send to the list...] In general I like the approach described in this proposal very much. Since I won't be attending the meeting, I wanted to give a little feedback here... 1. I am not sure I would agree with the claim that the responder role should _always_ be assigned to the "service provider", because the authors' arguments about avoiding denial of service only make sense if you assume service resource scarcity relative to consumer resource availability (assuming that an agreement is always a "trade" or contract of exchange between these two resource types). However, I believe that the entire notion of "provider" and "consumer" in inherently domain-specific, and therefore inseparable from the service term language. So, I might advocate that the existing context fields to associate provider/consumer roles with initiator/responder be dropped, but only because I don't think the core messaging pattern can really say anything about these roles to begin with. I think domain-specific concepts are necessary to really characterize these roles. Thus, I don't think there can be any normative statements in the standard for base agreement nor re-negotiation regarding the use of responder roles with providers or consumers. But, I think it would be fine to have some explanatory text about the various risks of reversing the signalling roles from the "natural" and asymmetric order that would exist in many domains. 2. Has any thought been given to the concrete rendering of this protocol? I immediately have the following ideas upon reading the message definitions: a. RenegotiationQuoteRequest and RenegotiationQuote could be easily mapped to resource property queries with a custom "quote query dialect". This was an expected use of extensibility in WSRF in the past, but I do not know how people view this today. The alternative, of course, is a new operation. Is there any concern about preparation of quotes being a slow or laborious process, and requiring an asynchronous exchange pattern or a resource pattern to allow cancellation of quote requests? b. RenegotationOffer and RenegotiationAccept/RenegotiationReject map easily to the two alternate rendering styles in WS-Agreement: CreateRenegotiatedAgreement (in) and response (out) for synchronous exchanges, in this case merging RenegotiationOfferAck with the accept or reject response; CreatePendingRenegotiatedAgreement (in) and AcceptAgreement/RejectAgreement (also in messages in opposite direction) for asynchronous exchanges, in this case mapping RenegotiationOfferAck to the factory response with the new pending renegotiated agreement; c. RenegotiationNotPossible could be a fault response as described and could also be exposed as a resource property on some agreements? In these renegotiation "factory" patterns, one approach would be to have the renegotiable Agreement resource support these additional patterns, i.e. to act as a factory for its superceding agreement. Or, a shared factory could take the existing agreement EPR as an input parameter. 3. I am assuming from my initial reading that the statement that acceptance of a renegotiation offer invalidates all other outstanding offers is also a point where loose consistency is desired. In other words, it is the responding party (who chooses to accept) who also decides which offers are outstanding and which he hasn't seen yet, in the case that offers are "in flight" and acknowledgements have not been sent. Is this the intention of the authors? If not, then I think some sort of sequence numbering is necessary on offers to help resolve these cases for message loss or delay. 4. I am not sure I follow the purpose of the RenegotiationNotPossible message. Is this a new terminal sub-state for Agreements? Or, can an agreement have this non-renegotiable status at one time but then later be re-negotiable? If the latter, I am not sure the meaning is well captured in the current discussion. It sounds like two different messages: one has the same meaning as a reject message in response to an offer, but with an added hint that other offers will also be rejected, i.e. a transient "don't waste my time right now" message; the other form sounds like just the "don't waste my time right now" advisory without being coupled with a specific offer rejection. Can the authors clarify the intent here? In any case, I am looking forward to seeing more concrete rendering proposals for this protocol extension. karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz(a)univaud.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software --------------------------------------------------------------------- Notice from Univa UD Postmaster: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This message has been content scanned by the Univa UD Tumbleweed MailGate. ---------------------------------------------------------------------

2 2

Re-negotiation Protocol Proposal
by mparkin＠bsc.es 16 Feb '08

16 Feb '08

Dear GRAAP-WG members. Please find attached a proposal for a re-negotiation protocol to be discussed in the GRAAP-WG sessions taking place at OGF22 in Boston. Peer Hasselmyer (NEC) will be giving a presentation on the protocol described in the attached document at OGF22. In the mean time if you have any questions please feel free to contact the authors. Regards, Michael.

3 2

Monitoring specified in an SLA
by Igor Rosenberg 07 Feb '08

07 Feb '08

Dear graap, We're currently focusing on monitoring the execution of an SLA (in a grid context), ie making sure the SLA is respected. The aim is to fire notifications when violations to the contract are detected. WS-Agreements (March 2007) offer service level objectives: <wsag:ServiceLevelObjective> <wsag:KPITarget> <wsag:KPIName>xs:string</wsag:KPIName> <wsag:Target>xs:any</wsag:Target> </wsag:KPITarget> <wsag:CustomServiceLevel> ... </wsag:CustomServiceLevel> </wsag:ServiceLevelObjective> Is this the place to specify which metrics are to be monitored, along with their expected values? Has anybody used this in real life, or even as a toy? Are there examples I should refer to? I've seen many use JSDL to specify the job description, specifying in detail the resource used. But JSDL doesn't say how the resource should behave while used (ie what monitoring information should it output, and what values are acceptable?). For example, I can say I want a 1GHz processor. Where and how do I specify that while running my job the CPU should have a mean load lower than 75% ? Thanks for any pointers you may have on monitoring SLAs for Grid. Best regards Igor ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente. Pueden estar protegidos por secreto profesional Si usted recibe este correo electronico por error, gracias de informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus ------------------------------------------------------------------

1 0