Re-Negotiation Wishlists

Every member is free to add comments to questions etc at the bottom of the Page (After the horizontal line). For a while I would propose that I (Toshi) maintain the contents above the horizontal line.

Questions (Please refer to the Attachment which is a revised text of presentation I made in GGF18) AI=Agreement Initiator, AR=Agreement Responder

1. New EPR or re-write the current WS-AG document? Probably the latter as race condition for the former could be serious. > Need some expert's comment. Reference [3] (see References Page) rightfully says that accountants don't use erasers. Whch means probably new EPR + Superceded by as suggested by Dominic is the right way. In order to avoid race conditions agreement state would need to have states such as is-being-superceded followed by either superceded or observed state. These states only have meaning if the Agreement Re-negotiation is implemented so can be considered as extension to the current Agreement Spec?? (2007/08/27 TN) Question how about the state of the new Agreement EPR? is-superceding followed by have-superceded or just use the original terms? (2007/08/27 TN)
2. Need to extend current WS-AG to tag Re-Negotiable Terms? Could be added as an option I think
3. Re-Negotiable Terms to be defined in the Template or can they be tagged in the Offer? Intuitively feel that this is more of an Agreement Responder's job so perhaps template would be better. But Might have AR tag a term as either renegotiable/nonrenegotiable and have the AI (Agreement Initiator)choose in the offer?
4. Renegotiable terms -SDTs and Guarantee Terms? Probably both..
5. Better faults to show reasons why the AP does not agree? (This is probably needed both for Negotiation and Re-negotiation, in order to give hints to AI for what AP can provide) Reasons could range from (Not compatible to the template / Cannot meet this SDT/GT (With a pointer to the term) / Cannot meet this SDT by this value..)
6. renegotiate ((SDT A and SDT B )or (SDT C))? What I meant here was to have AI send to AR a request to either renegotiate SDT A and SDT B or to renegotiate SDT C
7. Can both AI and AR ask for renegotiation ? (This one is rather crucial. Intuitively thinking, one would assume that both AI and AR would like to modify an established Agreement.. But protocol-wise, since the agreed agreement (with its EPR) is maintained on the AR side, a race condition could occur since the AI agrees to the AR's modification request, but the Agreement itself cannot be modified by the AR before the AI agrees to the modification. (Added modification 2007/08/22) This also has impact on where the port types are to be implemented. (Of course they can be put on both the AI and the AR) It seems both side need to be able to suggest. Thus have two (similar but different port types) depending on whether the Agreement Modification is requested by the AI(in which a new EPR is returned by the AR) or by the AR(in which a new EPR is passed as an extra argument to AI with modification already in. AI agreeds or discards it) (2007/08/27 TN)
8. Would need to add states to the Agreement runtime-state to specify states when agreement is being re-negotiated. (2007/08/22 TN)
9. Would expiration time be a candidate for renegotiation? (2007/08/22)
10. If both AI and AR can request Agreement Renegotiation, some names are necessary to show who requested the Agreement Renegotiation and who responded to it. Obvious candidate for the former is Requester but how should I call the other party? (Per Dominic's proposal but with a bit of a change would like to call the party who requested the Agreement Renegotiation, Agreement Modification Initiator (AMI) and the other party Agreement Modification Responder (AMR). (2007/08/27 TN)
11. What is the best way to extend WS-Agreement's Schema Definition? WS-AGRN Example for Extension

Here are some random comments/wishes/ideas (DB=Dominic Battré)

• 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? What would the ResourceProperties (e.g. the SDTs or GTs) look like in the intermediate state? (DB, 2007/08/22)
  • maybe it would be nice to have a "supercedes"/"superceededBy" attribute in the context (rather than a "relatedTo") (DB, 2007/08/22)
• ad "Can both AI and AR ask for renegotiation ?"
  • in my opinion, one very relevant scenario would be that a provider knows that it won't be able to fulfill a reservation in the future and would like to drop the SLA in advance for some reduced penalty (DB, 2007/08/22)
• ad "Better faults to show reasons why the AP does not agree?"
  • I think it would be nice to specify some syntactically meaningful fulfillable limits in a rejection. Suppose a user wants to extend a jobs runtime by "2 more hours", the AR might answer with "not possible, but I can give you 1 more hour". (DB, 2007/08/22)
• ad "If both AI and AR can request ... how should I call the other party?"
  • We have Agreement Initiator and Agreement Responder; how about Change Initiator/Requester and Change Responder? If the latter can do more than saying "yes/no" and send a counter-offer, this gets complicated however. (DB, 2007/08/22)
• I would like to see an ability to return several alternative offers upon an SLA request. I see two scenarios:
  • If the SDT of an SLA specify that at least a 2 GHz machine is needed, and the AR has 2.4 and 3.0 GHz available at different prices the AI might want to pick one. The AR needs to be able to specify whether all offers or one of the offers may be accepted. Or a job could be executed soon for a high price and at a different time for a lower price. This might be covered by different templates but I consider is quite difficult to specify the pricing mechanisms in the SLA template. (DB, 2007/08/22)
  • In a scenario with a broker, the broker might want to pretend to be a regular AR but return offers that originate from several resource providers. (DB, 2007/08/22)
• I think that offers need some kind of life-time. Even if this is difficult in distributed systems, offers cannot be held open infinitely. (DB, 2007/08/22)
• What about some kind of query language? ("By how much can I increase the execution time?") (DB, 2007/08/22)
• Suppose the AI wants to renegotiate. It sends a modified SLA to the AR. In the current WS-AgreementNegotiation draft (from 2004?), I think the AR would be allowed to respond with any new SLA offer ("no, but I can offer you this"). Should the protocol force that the negotiation comes to an end in order to prevent dialogs like "I want more CPUs" - "No, but I can give you more RAM" - "Well, but I want more CPUs" - "No, but I can give you more disk space" - .... Maybe the Requester wants to send some kind of template along with its renegotiation request as well. The template could restrict the counter-offer. (DB, 2007/08/22)

Attachments:

Excerpt　from Reliable Orchestration of Resources Using.pdf [ReNegotiationWishlists/Excerpt　from Reliable Orchestration of Resources Using.pdf] GRAAP18rev.pdf [ReNegotiationWishlists/GRAAP18rev.pdf]