[GRAAP-WG] Re-negotiation Protocol Proposal

[Michael Parkin]

[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.

</snip>

> 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.

</snip>

> 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