Subject: [Simple] WebDAV alternative to XCAP draft

From: Rohan Mahy <[email-masked]>
Date: Fri, 18 Feb 2005 08:45:24 -0800

Hi Folks,

Sometime in December or January, I started to hear fragmented reports  
that verifying idempotency during PUT and DELETE operations in early  
implementations of XCAP made the performance of these XCAP server drop  
considerably.  I can think of two reasonable explanations for these  
reports:

1) These implementations where written inefficiently.  When optimized  
the actual performance of idempotency checks is fine for production  
systems.

or

2) There is something inherent about the flexibility of XCAP that makes  
it hard to quickly verify the idempotency requirement.

Currently SIMPLE is using XCAP for resource-lists and auth-lists. While  
the arbitrary depth functionality of XCAP is useful for some  
applications (ex: I understand that this was particularly attractive  
for Joel's application), our applications don't require the complete  
flexibility of XCAP.

Consequently, I wrote an "Escape Hatch" proposal that sketches the  
possibility of using ordinary WebDAV to get the functionality we are  
using.  I quite like this approach and if we were starting over again,  
this would be my first choice. However, the working group has invested  
a lot of energy in XCAP and it promises a lot of flexibility for future  
IETF application configuration work.

So, I would like to quickly find out what kind of PUT and DELETE  
performance folks are getting from XCAP implementations when  
idempotency checks are turned on.  Folks with implementations, please  
speak up.

It would be nice to verify that everything is fine and go back to our  
regularly scheduled program. If something is really wrong, I'd like  
folks to consider my proposal, which is at:

	http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- 
alternative-00.txt

many thanks,

-rohan

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2005 16:45:37 -0500

Rohan,

Your draft makes the statement that the check for idempotency is 
reducing the performance by orders of magnitude. I don't see how the 
protocol can fundamentally cause that to happen (as opposed to some kind 
of implementation issue).

As proof of that, let me suggest an approach that looks like it would 
cause, at worst, a 2x cost in performance.

What you do is this. Process the PUT, and when you are done, hold onto 
the pointer for the object you just inserted into the document. Then, 
run the processing as if a GET was just applied to the same URI as in 
the PUT. Check the pointer for the object retrieved. If it matches, then 
the reques was idempotent, and a 200 OK to the original PUT is returned. 
Otherwise, the 409.

I cannot understand how this algorithm could ever be more expensive than 
actually executing a GET followed by a PUT, and in the worst case, a GET 
should be as expensive as a PUT. That would put an upper bound on this 
algorithm of 2x; i.e., the processing performance of xcap with 
idempotency checks should never be worse than half of the processing of 
performance without them.

What am I missing?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Feb 2005 17:24:26 -0600

On Feb 18, 2005, at 10:45 AM, Rohan Mahy wrote:

> I'd like folks to consider my proposal, which is at:
>

This proposal must be deeply flawed, because I think I actually  
understand parts of it. I kind of like that feeling -- it doesn't  
happen often :-) !

One question: You mention the possibility of pipelined commands and  
touch very briefly on simultaneous operations. Would it be appropriate  
to consider locking the immediate parent collection before updating  
more than one child of that collection in a pipelined mode?

--
dean

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 19 Feb 2005 08:28:54 -0800

Yes,  you could lock the immediate parent.  I did not want to rely on  
locking support in the client, but almost all servers support locking.   
Locking isn't needed for inserts, but it is useful for bulk modify and  
bulk delete.

thx,
-r

---

From: Dean Willis <[email-masked]>
Date: Sun, 20 Feb 2005 22:08:14 -0600

On Feb 19, 2005, at 10:28 AM, Rohan Mahy wrote:

>  Locking isn't needed for inserts, but it is useful for bulk modify 
> and bulk delete.
>
But doesn't the locking operation effectively transform a 
non-idempotent sequence into a single idempotent transaction?

--
Dean

---

From: jari urpalainen <[email-masked]>
Date: Mon, 21 Feb 2005 10:28:14 +0200

> 	http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- 

As I do have some implementation experience on this, some comments...

Jonathan also noted that the idempotency check isn't that difficult as
you are saying, i.e. you'll just have to do a simple XPath evaluation
after a put/delete request to fulfill a valid xcap request. Once you'll
have already parsed the XPath query, you'll just have to evaluate the
request again against the document and usually you'll don't even have to
check the full location path but only the last or the last two steps.
(and btw. it is somewhat vague to speak about idempotency constraint
here as it can be easily fulfilled with conditional requests, i.e. this
checking constraint is more like an xcap thing). And still in my
reference implementation this checking has really a minor impact on the
performance which is mostly suffered by the schema validation which will
take orders of magnitude more time than this checking. And I don't see a
big difference in this validation constraint between the two approaches.

This is not to say that using WebDAV is totally wrong here. Actually, I
could easily see that e.g. locks could be used together with the base
xcap but it would be complementing technique not replacing something
onto which we have put quite some effort.

br,
Jari