Subject: RE: Garbage collection in publish RE: [Simple] draft-ietf-simple-publish-reqs-00

From: [email-masked]
Date: Mon, 3 Mar 2003 09:34:12 +0200

Think of the famous scenario where I'm at the office with my PUA publishing a tuple that I'm "in the office". Now I go home and forget to turn that off, keeping in mind that there are refreshes going on by that PUA.

At home, I switch my home pc on and my PUA there publishes a tuple to override the one sent by the PUA at the office.

In this case, a stack model does not work, my watchers would get my presence "in the office, "at home" alternating throughout the night.

A replace model looks better, once I publish from home, the compositor simply stops accepting publications from the office. But this fails once I go back to the office the next day, leaving my home pc running (how do I now tell the compositor to ignore the tuple published from home and start accepting ones from the office? they are both now publishing refreshes).

The "winner" model is even better. But what is an example of that local policy? especially when the two PUAs are not synchronised to publish at the same time?

I think there is a need for a PUA to send some sort of flag in the publish telling the compositor from which PUA to accept publications from. Example is a flag saying "this is not a refresh". When I go to the office in the morning, I press a button on my PUA for it to send a new publish with that flag set. This is a kind of replace model combined with winner :)

Of course time stamping helps here also, but is time stamp set to when the tuple is created or set every time before a tuple is published. If it is the former, then that could be used by the compositor (local policy) to determine which PUA is the winner. When I go to the office the next day, I re-publish that tuple with an updated time stamp.

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 3:32 PM
> To: [email-masked]; [email-masked]; Isomaki Markus
> (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); [email-masked]
> Subject: Garbage collection in publish RE: [Simple]
> draft-ietf-simple-publish-reqs-00
> 
> 
> Hi,
> 
> Comments inline.
> 
>  > -----Original Message-----
>  > From: ext Sean Olson [mailto:[email-masked]]
>  > Sent: 27 February, 2003 11:27
>  > To: Niemi Aki (NMP/Helsinki); [email-masked]; 
>  > Isomaki Markus
>  > (NRC/Helsinki); Kiss Krisztian (NRC/Tampere); [email-masked]
>  > Subject: RE: [Simple] draft-ietf-simple-publish-reqs-00
>  > 
>  > > So it seems the main issue is garbage collection. I
>  > > think there is a requirement here not yet covered in
>  > > the reqs-draft, that the PUBLISH mechanism must
>  > > provide the composer means to do garbage collection
>  > > in case a PUA dies. I think this implies a hearbeat
>  > > / refresh type function for the publications.
>  > > 
>  > > Then there's another question on how a composer does
>  > > grabage collection. I think the two options
>  > > presented in this thread are the "replace" model and
>  > > the "stack" model. In theory, the stack model is
>  > > better, but I can't think of an actual use case
>  > > scenario where that would be striclty needed. So to
>  > > avoid the complexity, I'm fine with the replace
>  > > model.
>  > 
>  > I'm confused about these two models. Are you speaking
>  > about two different PUAs publishing to the same
>  > tuple -or- are do you mean two different PUAs 
>  > publishing to two different tuples that the 
>  > composer aggregates? I'm trying to understand how
>  > these models relate to garbage collection (and if
>  > there are other models we need to consider)
>  > 
>  > I assume you are talking about 
>  > two PUAs publishing to the same tuple.
> 
> Yes.
> 
>  > In the stack model, when one
>  > PUA dies its state is popped and the second PUA's
>  > state becomes the new state for that tuple. 
>  > 
>  > In the replace model, I assume you mean latest
>  > PUA wins and therefore when one PUA dies, the other
>  > would have to re-PUBLISH its state for it to take
>  > effect -- how does the second PUA know to re-PUBLISH
>  > and when does that occur?
> 
> I was assuming that the second PUA would simply re-publish 
> when it is its time to refresh. In fact, the stack model is 
> only needed if publications from different PUAs had different 
> expirys (like one being a multiple of the other). But if the 
> composer can always guarantee that the refresh rates are 
> aligned, I think the two models are the same.
> 
> And since the composer can always lower a publisher's rate, I 
> guess the only thing missing is "Min-Expires" for the opposite case?
> 
>  > In a possible third model, local policy at the
>  > composer
>  > determines the "winner". It's not necessarily a stack
>  > or a last-one-wins model. In this case, it may not
>  > be necessary for the second PUA to re-PUBLISH.
> 
> This is true, there are actually three models. Out of the 
> three, I think the "replace" model and the "winner" model are 
> the relevant ones.
> 
> Cheers,
> Aki
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Mar 2003 08:19:07 -0500

It sounds like you're inventing WebDAV, one requirement at at time...