Subject: [Simple] PUBLISH: atomicity problem

From: [email-masked]
Date: Mon, 14 Jul 2003 20:58:57 +0300

All,

I'll try to summarize the issues w.r.t. the atomicity of publication here in an attempt to converge the discussion towards a solution to this problem. BTW, I realized that my slides in the SIMPLE session were perhaps not crystal clear on what the problem at hand really was, so my apologies for that.

The core problem is this: 

EPA X sends a PUBLISH with {a, b, c}, after which EPA Y publishes {a, b}. When EPA X tries to refresh its publication of {a, b, c}, the request fails because of a collision, resulting in the EPA X quitting. EPA Y still refreshes its publication of {a, b}, which means {c} expires and goes away. As a result, the publication process has lost information of {c}. This is unacceptable, and with the current versioning mechanism, this can't be remedied by composer policy, for example.

Instead, to get around the above problem, what you send in a PUBLISH needs to match the atomic element of the published information. So each PUBLISH needs to contain a single tuple, because the versioning and expiration all work on the single atomic element level anyway.

This has the apparent drawback in that the PUA has to wait for a 200 OK after each PUBLISHed tuple before it can PUBLISH the next one. This occurs upon every refresh cycle, and in systems with high latency, may become a major issue in terms of performance.

Ways to get around this inefficiency:
	- Remove the restriction on overlapping requests, i.e., allow "pipelining"
	  of PUBLISH requests
	- Treat the publisher of each tuple as a separate EPA, and therefore not
	  subject to this restriction in the first place (seems like cheating...) 

In conclusion, my proposal is to go with having always a single tuple in a PUBLISH, and allow overlapping PUBLISH requests. To my knowledge, this would fulfill all the related requirements and solve the issue.

Thoughts?

Cheers,
Aki

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