[Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[Nathaniel McCallum]

On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote:
> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote:
> > Attached is the latest patch. I believe this includes all of our
> > discussions up until this point. However, a few bits of additional
> > information are needed.
> >
> > First, I have renamed the plugin to ipa-otp-counter. I believe all
> > replay prevention work can land inside this plugin, so the name is
> > appropriate.
> >
> > Second, I uncovered a bug in 389 which prevents me from validating the
> > non-replication request in bepre. This is the reason for the additional
> > betxnpre callback. If the upstream 389 bug is fixed, we can merge this
> > check back into bepre. https://fedorahosted.org/389/ticket/47919
> >
> > Third, I believe we are now handling replication correct. An error is
> > never returned. When a replication would cause the counter to decrease,
> > we remove all counter/watermark related mods from the operation. This
> > will allow the replication to apply without decrementing the value.
> > There is also a new bepost method which check to see if the replication
> > was discarded (via CSN) while having a higher counter value. If so, we
> > apply the higher counter value.
> 
> For me the code is good. It took me some time to understand the benefit 
> of removing mods in preop.
> In fact I think it is a good idea, as it prevents extra repair ops and 
> also make more easy the computation of the value to set in repair mod.
> >
> > Here is the scenario. Server X receives two quick authentications;
> > replications A and B are sent to server Y. Before server Y can process
> > server X's replications, an authentication is performed on server Y;
> > replication C is sent to server X. The following logic holds true:
> >   * csnA < csnB < csnC
> >   * valueA = valueC, valueB > valueC
> >
> > When server X receives replication C, ipa-otp-counter will strip out all
> > counter mod operations; applying the update but not the lower value. The
> > value of replication B is retained. This is the correct behavior.
> >
> > When server Y processes replications A and B, ipa-otp-counter will
> > detect that a higher value has a lower CSN and will manually set the
> > higher value (in bepost). This initiates replication D, which is sent to
> > server X. Here is the logic:
> >   * csnA < csnB < csnC < csnD
> >   * valueA = valueC, valueB = valueD, valueD > valueC
> >
> > Server X receives replication D. D has the highest CSN. It has the same
> > value as replication B (server X's current value). Because the values
> > are the same, ipa-otp-counter will strip all counter mod operations.
> > This reduces counter write contention which might become a problem in
> > N-way replication when N>2.
> 
> I think we should rather let the mods going on. So  that the full 
> topology will have
> valueD (or valueB)/csnD rather having a set of servers having 
> valueD/csnB and an other set valueD/csnD.

I think you misunderstand. The value for csnD is only discarded when the
server already has valueB (valueB == valueD). Only the value is
discarded, so csnD is still applied. The full topology will have either
valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by
substitution, all servers have valueD w/ csnD.

Nathaniel