From igor.rosenberg at atosresearch.eu Thu Feb 7 04:10:26 2008 From: igor.rosenberg at atosresearch.eu (Igor Rosenberg) Date: Thu, 07 Feb 2008 11:10:26 +0100 Subject: [GRAAP-WG] Monitoring specified in an SLA Message-ID: 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: xs:string xs:any ... 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 ------------------------------------------------------------------ From mparkin at bsc.es Fri Feb 15 04:47:36 2008 From: mparkin at bsc.es (mparkin at bsc.es) Date: Fri, 15 Feb 2008 11:47:36 +0100 (CET) Subject: [GRAAP-WG] Re-negotiation Protocol Proposal Message-ID: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal.pdf Type: application/pdf Size: 218081 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080215/e4ea2ac2/attachment.pdf From philipp.wieder at udo.edu Fri Feb 15 05:11:59 2008 From: philipp.wieder at udo.edu (Philipp) Date: Fri, 15 Feb 2008 12:11:59 +0100 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> References: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> Message-ID: <47B5737F.2030005@udo.edu> And the email went through :-) Philipp. mparkin at bsc.es schrieb: > 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. From karlcz at univaud.com Fri Feb 15 23:35:55 2008 From: karlcz at univaud.com (Karl Czajkowski) Date: Sat, 16 Feb 2008 12:35:55 +0700 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <20080216052556.GA3569@granite.bbswl> References: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> <20080216052556.GA3569@granite.bbswl> Message-ID: <20080216053555.GC3569@granite.bbswl> [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 at 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. --------------------------------------------------------------------- From t-nakata at cw.jp.nec.com Sat Feb 16 17:40:19 2008 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Sun, 17 Feb 2008 08:40:19 +0900 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> References: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> Message-ID: <004101c870f5$4a841e10$b084380a@Sakurai> Hello: I am very grateful?for this proposal. Due to other commitments, I 've been in low-profile about WS-AG-Re-neg. . But I will participate in the GRAAP session and hope to have discussion on this. (I'll try to read the paper in more detail some time during this week.) Best Regards and 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: graap-wg-bounces at ogf.org > [mailto:graap-wg-bounces at ogf.org] On Behalf Of mparkin at bsc.es > Sent: Friday, February 15, 2008 7:48 PM > To: graap-wg at gridforum.org > Cc: peer at hasselmeyer.com > Subject: [GRAAP-WG] Re-negotiation Protocol Proposal > > 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. From mparkin at bsc.es Mon Feb 18 13:41:15 2008 From: mparkin at bsc.es (Michael Parkin) Date: Mon, 18 Feb 2008 20:41:15 +0100 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <20080216053555.GC3569@granite.bbswl> References: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> <20080216052556.GA3569@granite.bbswl> <20080216053555.GC3569@granite.bbswl> Message-ID: [Sorry for the delay, my first attempt to send this bounced too] Hi Karl, Many thanks for your reply and comments. Please see our responses below. Michael. On 16 Feb 2008, at 06:35, Karl Czajkowski wrote: > 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). Yes, we do assume that a contract is formed between the provider and the customer for some exchange, but what that contract is for and what is exchanged is, like contract law, outside the scope of the protocol. We are not claiming that the responder in the re-negotiation protocol should always be the service provider. This is because the service provider can send quote messages to the customer to initiate re- negotiation. As described in the paper, we can map the service provider onto the WS-Agreement "responder" role and we provided this example because of the audience the proposal was intended for, but these two roles are different. > However, I believe that the entire notion of "provider" and > "consumer" in inherently domain-specific, and therefore inseparable > from the service term language. We believe the opposite is true: providers or customers can supply and consume anything, and these roles are inherently domain-independent. In short, the messages and the content of those messages (or "service term language") are separable and have to be in order for the protocol to be used across different domains, like the protocol inherent in contract law is. > 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. a) About "the existing context fields". Can you explain what you mean by this as we don't use this phrase in our paper. Do you mean the protocol roles? b) You're right - the protocol cannot and does not say anything about the roles of supplier and customer apart from that they are suppliers and customers of something. c) If you think domain-specific concepts are necessary to characterise these roles, can you give us some examples where you feel this would help? > 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. I'm sorry, I don't understand the argument here. Please can you clarify. > 2. Has any thought been given to the concrete rendering of this > protocol? I immediately have the following ideas upon reading the > message definitions: By "rendering" do you mean implementation? If so, then yes we have a proof-of-concept implementation. As we wrote in the proposal, we're currently producing a paper on this which will also be circulated to the group. > 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? This is jumping ahead to considering how this can be mapped onto a WS (particularly WSRF) implementation. Our first step is to define and agree on the abstract protocol, then provide a mapping to WS (and other stacks), though, as stated above, we will give an example implementation in a following paper. This is why we give an explanation of the protocol behaviour and not interface definitions, although we included some explanation of how it could be mapped to WS- Agreement because of the audience the proposal was intended for. As I'm sure you're aware, not detailing implementation is common in protocols - for example, see Lamport's description of the Paxos algorithm [1] that doesn't talk at all about actual implementation. > 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; Again, these are considerations for an implementation. However, in the abstract protocol there is nothing to stop the provider sending the RenegotiationOfferAck with the Accept or Reject message. We make the distinction because there may be cases when there will be a delay between the provider sending the acknowledgement and deciding whether it can accept or reject the offer. (Note that his is how Amazon works, they send an email acknowledgement initially but then accept your offer and form the contract when they tell you they're shipping your goods). > 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? Of course, but see the above answers above about not wanting to tie this to any implementation at the moment. > 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? a) About "the responding party (who chooses to accept)": the service provider (who always chooses to accept an offer) may be the initiator of the re-negotiation as we described above. b) Yes, this is because in contract law the offeree (the service provider) always gets the final say. > 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? You're right in that RenegotiationNotPossible is a type of advisory message. But, if sent in response to an offer it has the same effect as a Reject message. Re-reading the proposal we agree that this is not captured well and will update the document accordingly. [1] http://pdos.csail.mit.edu/6.824/papers/paxos-simple.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20080218/d82ad7ed/attachment.html From karlcz at univaud.com Sun Feb 24 21:32:48 2008 From: karlcz at univaud.com (Karl Czajkowski) Date: Mon, 25 Feb 2008 10:32:48 +0700 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: References: <18744.192.168.6.1.1203072456.squirrel@webmail.bsc.es> <20080216052556.GA3569@granite.bbswl> <20080216053555.GC3569@granite.bbswl> Message-ID: <20080225033248.GC4950@crater.lan> [Apologies for the delay, I've been away from the office...] On Feb 18, Michael Parkin modulated: > We are not claiming that the responder in the re-negotiation protocol > should always be the service provider. This is because the service > provider can send quote messages to the customer to initiate > re-negotiation. As described in the paper, we can map the service > provider onto the WS-Agreement "responder" role and we provided this > example because of the audience the proposal was intended for, but > these two roles are different. > OK, I think I missed your distinction between "renegotiation responder" and "WS-Agreement responder" on my initial reading. So, if you are saying each round of renegotiation can be offered by either party of the existing agreement, I think I could accept this flexibility... it is more general than I had expected. As for the other topic of labeling roles, I think we are actually saying the same thing and just having a terminology clash. My perspective is perhaps best illustrated by this example: - Consider an agreement domain where agreements represent the execution of compute jobs. - Traditionally HPC practitioners would say that the the party defining a job to run is "consuming computer time" and the the compute resource operating party is "providing computer time". Because of this, most people would agree also with having the job-defining party be the initiator (offerer) in the agreement process. - In a multi-level brokering extension to this environment, multiple compute resource operating parties might be fighting for the same jobs and it makes sense to think of a broker/reseller as "providing jobs" and a compute resource operator as "consuming jobs". In this environment, the resource operators may need to be the agreement initiators (offerers) because it is better to "waste" some of their time on offered-but-not-committed agreements rather than to let the (scarce) jobs in the broker get live-locked. Where I keep getting stuck in terminology is that the agreement protocol roles of initiator and responder do not always map to the same operational roles in these job execution scenarios. There are always the same two domain-specific operational roles of "job defining party" and "job executing party", but they associate with different signalling roles. Consistent (I think) with your earlier statements about avoiding resource waste, the negotiation protocol roles should be associated with an abstract sense of who is providing the scarce or less fungible resource/service. But, to identify who is providing this resource would require reference to domain-specific roles, since it is not a static property of all job agreements. So, in my view we should have two "party-to-role" mappings to specify: 1. Which signaling party serves each agreement role 2. Which domain-specific party serves each service providing role I don't think either of these can be implied via the other. I also don't think the situation differs for the first agreement versus the re-negotiated agreement. It is my belief that (1) should be addressed in the negotiation protocol message envelope, while (2) should be left completely to the domain-specific service language. I think we made mistakes previously in attempting to encode (2) in the WS-Agreement envelope. I'm still struggling to feel confident that I understand your statements in this area with respect to contract law, etc. How would contract law look upon my brokering scenario, where a reversal of the offer/accept signalling roles is desired? > > 2. Has any thought been given to the concrete rendering of this > protocol? I immediately have the following ideas upon reading > the > message definitions: > > > By "rendering" do you mean implementation? If so, then yes we have a > proof-of-concept implementation. As we wrote in the proposal, we're > currently producing a paper on this which will also be circulated to > the group. > By rendering I mean concrete protocol designs which would be the subject of standardization, e.g. XML/SOAP "bytes on the wire". Implementation would be various software providers writing software which complies with this standard. I'll be surprised if there is much (any?) working group debate of the abstract offer/accept renegotiation protocol, as it seems quite natural, simple, and general to me. But, where we've seen most of the debates previously has been in how these abstract concepts appear in actual concrete message schema... > a) About "the responding party (who chooses to accept)": the service > provider (who always chooses to accept an offer) may be the initiator > of the re-negotiation as we described above. > Sorry for the confusion of terms again. Every time I've said "initiator" I meant "offerer" in your terms I think. I meant WS-Agreement "Initiator" who performs the first step of the offer/accept exchange. karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz at 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. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- From karlcz at univaud.com Fri Feb 29 04:35:04 2008 From: karlcz at univaud.com (Karl Czajkowski) Date: Fri, 29 Feb 2008 17:35:04 +0700 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <20080229081611.GC21529@crater.lan> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> Message-ID: <20080229103504.GC4937@crater.lan> [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 at 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. From t-nakata at cw.jp.nec.com Fri Feb 29 16:51:52 2008 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Sat, 1 Mar 2008 07:51:52 +0900 Subject: [GRAAP-WG] FW: Re-negotiation Protocol Proposal Message-ID: <001a01c87b25$acc028a0$b084380a@Sakurai> 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 at 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 at 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. From t-nakata at cw.jp.nec.com Fri Feb 29 17:44:05 2008 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Sat, 1 Mar 2008 08:44:05 +0900 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <20080229103504.GC4937@crater.lan> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> <20080229103504.GC4937@crater.lan> Message-ID: <002901c87b2c$f841d2e0$b084380a@Sakurai> Hi Again: > 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) > These are somethngs I can guess and feel provide an elegant solution, but I feel that the implicit messages needed here between the Agreement Responder and the Agreement Factory would needed to be spelt out or (My guess) would always, fail.. #Karl please tell me that I'm wrong... So for the moment, I personally feel that a more simple protocol either using PendingXXX would be better.. #Your thoughts everyone :-) Best Regards Toshi @ safely moved from freezing East Coast US to a warmer Silicon Valley ----- 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) From Wolfgang.Ziegler at scai.fraunhofer.de Fri Feb 29 17:57:16 2008 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Sat, 01 Mar 2008 00:57:16 +0100 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <002901c87b2c$f841d2e0$b084380a@Sakurai> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> <20080229103504.GC4937@crater.lan> <002901c87b2c$f841d2e0$b084380a@Sakurai> Message-ID: <47C89BDC.7020304@scai.fraunhofer.de> Hi Toshi & Karl, I am about to re-draw the slides of Toshi for inclusion in a document that presents the ideas of the three presentations given in the second and third GRAAP session. I will also try to re-draw slide 7 taking into account the discussion on the list and then sent it to the list again to see whether I understood Toshi, Karl and the ongoing discussion ;-) Best regards Wolfgang Toshiyuki Nakata schrieb/wrote: > Hi Again: >> 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) >> > > These are somethngs I can guess and feel provide an elegant solution, > but I feel that the implicit > messages needed here between the Agreement Responder and the > Agreement Factory would needed to be spelt out or (My guess) would always, > fail.. > > > #Karl please tell me that I'm wrong... > > So for the moment, I personally feel that a more simple > protocol either using PendingXXX would be better.. > > #Your thoughts everyone :-) > Best Regards > Toshi @ safely moved from freezing East Coast US to a warmer Silicon Valley > > > ----- > 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 -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2093 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080301/c5d1ec16/attachment.bin From t-nakata at cw.jp.nec.com Fri Feb 29 22:17:18 2008 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Sat, 1 Mar 2008 13:17:18 +0900 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <47C89BDC.7020304@scai.fraunhofer.de> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> <20080229103504.GC4937@crater.lan> <002901c87b2c$f841d2e0$b084380a@Sakurai> <47C89BDC.7020304@scai.fraunhofer.de> Message-ID: <001801c87b53$230855f0$b084380a@Sakurai> HI: > > I am about to re-draw the slides of Toshi for inclusion > in a document that presents the ideas of the three presentations > given in the second and third GRAAP session. > I think it should? Interesting... 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/20080301/f8312e30/attachment.bin