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

---

From: Robert Sparks <[email-masked]>
Date: 15 Jul 2003 11:09:51 +0200

Another way to state this conclusion is that we need to report
success or failure of publishing each atomic element in an independent
fashion. One quick and easy way to achieve that property is to allow
only one atomic element per PUBLISH request.

I think I heard another way to do this mentioned during the meeting,
where we move reporting the success/failure and any feedback from
the attempt to publish each tuple into the message instead of trying
to capture it all on the status line. For example (I think this is 
what I heard suggested during the meeting), for presence, we could
publish an entire pidf document with several tuples and in the presence
response return an xml document with one element per tuple discussing
the disposition of attempting to publish that tuple.

Something along the lines of the following (an example to convey the
concept, not a proposal of a syntax)
<publish-results>
  <tuple id="023cfdsf3">
   <success etag="39009sdf" expires="1800"/>
  </tuple>
  <tuple id="990429834">
   <failure/>
  </tuple>
</publish>

If we were to pursue such an optimization, it might make sense to
look at how to specify a separate etag value in the publish (currently
what we put in an If-Match header) for each atom in the published
document.

RjS

---

From: Robert Sparks <[email-masked]>
Date: 15 Jul 2003 11:09:51 +0200

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 10:57:18 -0400

Another way to approach this is to make it a problem for the publisher 
to deal with. If the publisher wants, it can publish each tuple 
separately, with the positive and negative consequences you mention.

As an optimization, the publisher can batch up a bunch of tuples and 
hope to publish them together. If this fails, it should fall back to 
publishing them independently. Once it discovers which ones can be 
successfully published, it can batch those up in future updates, 
omitting the ones that failed.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 10:57:18 -0400

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 15:42:06 -0400

I was about to post a note on agreeing with Aki.  I was also going to 
say that we might want the body to also be the atomic unit, so that 
when you publish a tuple, the body is an XML fragment for the tuple. 
Then, it ocurred to me that we were really far down the complexity 
ramp here. So, I thought about what we could do to really back out of 
this mess entirely. Here is my idea.

In the beginning, PUBLISH was easy. Each PUA published its own view of 
the presence of the presentity. It had no knowledge of other PUA. It 
published a complete presence document which represented what it 
thought was the full presence of the presentity. Indeed, if there was 
only one PUA, it would be the full presence of the presentity. There 
was no way for one PUA to overwrite the published data from another. 
The tuple IDs didn't need to have cross-PUA scope. No naming 
conventions or anything. The compositor could combine these and modify 
them as it chose. Each represented a unique and different piece of 
info about the presentity. A useful bit of information was this 
"Pstream-ID", which uniquely identified the publisher. You can think 
of the Pstream-ID as a way of scoping the tuple IDs. Each tuple ID is 
defined only within the scope of a Pstream-ID, and each publisher has 
to have a unique PStream-ID.

It all got complicated when we decided to try and solve a bigger 
problem, where PUA could override information about other PUA. That 
introduced all kinds of problems. We needed to define the atomic 
information of published presence. We need to resolve tuple naming. We 
need to worry about this issue about whether a publish has one or more 
tuples. We needed to add Etags and If-Modified-Since. We need to worry 
about how to figure out what it means for the system to "wait for 
human input" in cases where thats not possible. We don't know how to 
do that yet.

Perhaps we should reconsider whether we want to solve this problem 
this way. We have only one use case - when I leave my PC at the office 
with a presence state that is wrong, and I want to fix it at home. 
Well, this is a nice feature, but is it worth all of the complexity at 
this point? There are other ways to deal with it. In fact, I can think 
of two alternatives:

1. You could use the auth policy to simply disable the PC's data from 
being placed in notifications, and then publish a separate tuple 
(i.e., new piece of independent information) from home. Thats not as 
good (PC still refreshes useless state), but its lots simpler than the 
route we are on.

2. You could design a system which only allowed one PUA at a time 
(akin to the current model in AIM and YIM). This would manifest itself 
as composition policy. The compositor would only use the published 
document from the PUA which started publishing most recently - that 
is, when its Pstream-ID first appeared. This would also achieve the 
effect of disabling the work PC's state when you arrive at home.

So, to be concrete, I would propose the following:

1. Publications carry complete presence documents, representing the 
complete presence state of the PUA as far as it knows.

2. Publishers are identified by a unique PStream-ID, chosen by the 
publisher. Copying someone elses Pstream-ID is not allowed, and 
behavior in this case is not defined.

3. There is no ability to overwrite someone elses presence document or 
their tuples. Each publisher publishes independent information.

4. We eliminate the Etag, If-Modified-Since, and atomicity/segment 
discussions from Publish.

5. Compositors can combine the publsihed information however they 
like. There is no need to carry through tuple IDs from publication to 
notifications.

6. If you want to block a tuple from getting into a notify, you 
identify it by a distinguishing property rather than by tuple ID.

I believe this approach works nicely for other things too. In the case 
of winfo, where you have lots of presence servers, each publishing 
winfo for the subscriptions they have, its the same. Each publisher (a 
presence server), publishes the complete view of the state - its own 
subscriptions. There is no overlap between servers. The compositor 
combines these together using a basic policy (combine subscriptions 
together that are for the same presentity), and thats it.

I believe it works for mwi too.

I really feel that it is important that we make some simplifications 
so that we can make rapid progress here. I don't think we lose much 
since we can still get the desired feature; we just get it in a 
different way.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 15:42:06 -0400

Thoughts?

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 15:55:14 -0400

This does seem much simpler. I wonder if combining this with an explicit 
remove operation - "drop this Pstream/tuple-id tuple" - would avoid the 
rather round-about way of cleaning up dead state noted below, without 
having to worry about atomicity, last-modified-issues and unique naming.

Jonathan Rosenberg wrote:

> say that we might want the body to also be the atomic unit, so that when 
> you publish a tuple, the body is an XML fragment for the tuple. Then, it 
> ocurred to me that we were really far down the complexity ramp here. So, 
> I thought about what we could do to really back out of this mess 
> entirely. Here is my idea.
> 
> published a complete presence document which represented what it thought 
> was the full presence of the presentity. Indeed, if there was only one 
> PUA, it would be the full presence of the presentity. There was no way 
> for one PUA to overwrite the published data from another. The tuple IDs 
> didn't need to have cross-PUA scope. No naming conventions or anything. 
> The compositor could combine these and modify them as it chose. Each 
> represented a unique and different piece of info about the presentity. A 
> useful bit of information was this "Pstream-ID", which uniquely 
> identified the publisher. You can think of the Pstream-ID as a way of 
> scoping the tuple IDs. Each tuple ID is defined only within the scope of 
> a Pstream-ID, and each publisher has to have a unique PStream-ID.
> 
> about how to figure out what it means for the system to "wait for human 
> input" in cases where thats not possible. We don't know how to do that yet.
> 
> Perhaps we should reconsider whether we want to solve this problem this 
> way. We have only one use case - when I leave my PC at the office with a 
> presence state that is wrong, and I want to fix it at home. Well, this 
> is a nice feature, but is it worth all of the complexity at this point? 
> There are other ways to deal with it. In fact, I can think of two 
> alternatives:
> 
> being placed in notifications, and then publish a separate tuple (i.e., 
> new piece of independent information) from home. Thats not as good (PC 
> still refreshes useless state), but its lots simpler than the route we 
> are on.
> 
> 2. You could design a system which only allowed one PUA at a time (akin 
> to the current model in AIM and YIM). This would manifest itself as 
> composition policy. The compositor would only use the published document 
> from the PUA which started publishing most recently - that is, when its 
> Pstream-ID first appeared. This would also achieve the effect of 
> disabling the work PC's state when you arrive at home.
> 
> 
> publisher. Copying someone elses Pstream-ID is not allowed, and behavior 
> in this case is not defined.
> 
> 5. Compositors can combine the publsihed information however they like. 
> There is no need to carry through tuple IDs from publication to 
> notifications.
> 
> 6. If you want to block a tuple from getting into a notify, you identify 
> it by a distinguishing property rather than by tuple ID.
> 
> 
> of winfo, where you have lots of presence servers, each publishing winfo 
> for the subscriptions they have, its the same. Each publisher (a 
> I really feel that it is important that we make some simplifications so 
> that we can make rapid progress here. I don't think we lose much since 
> we can still get the desired feature; we just get it in a different way.
> 
> Thoughts?
> 
> -Jonathan R.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 15:55:14 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 16:37:40 -0400

> having to worry about atomicity, last-modified-issues and unique naming.

I don't follow. Thats exactly what we were doing before. The home PC 
will send your "drop this pstream/tuple-id" in a publish (I assume 
that is what you mean), and then the work PC refreshes, and now we 
have the conflict all over again.

One other point on my proposal. One unresolved issue which we had was, 
if you want to delete a tuple using Expires:0, what information in the 
publish identified the tuple? In the proposal I am making, its easy. 
The Publish has an Expires:0 and a Pstream-ID header. The published 
document from that pstream is deleted.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2003 16:37:40 -0400

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 18:18:49 -0400

I generally like this idea, but maybe it is still too complex.

Why do we need the Pstream-ID? Simply say each publisher must choose 
unique tuple ids and leave it at that.

Regarding how to set up blocking of the ones you don't want, instead of 
pstream, how about simply having each publisher include its identity in 
each tuple, as an attribute? This could be filtered out for most users.

	Paul

Jonathan Rosenberg wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 18:18:49 -0400

Paul