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

From: [email-masked]
Date: Thu, 27 Feb 2003 15:32:15 +0200

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