Re: ACK of register and purge packets

[James Luciani <[e-mail]>]

David,

> >If you send a purge to a system component, it will either process it or it will not.  If
> >it does, and it sends you an acknowledgement, then you should not repeat the purge.  If
> >it does and it doesn't send you an acknowledgement, then it will probably not send one
> >for any new purge(s) sent to it (so repeating the purge is pointless). If it does not
> >process the purge, then either it did not receive the purge or it is too busy to process
> >it in a timely way.  Considering the potential consequences of the change that made a
> >purge necessary, this latter case may be more likely than might otherwise be the case.
> 
> As proposed earlier, why not add an "acknowledgement request" flag in
> the Purge packet.  There are environments and configurations where
> acknowledgments are very useful, and I agree with you that there are
> other environments/configurations where it is actually problematic.
You are stating a case for exactly one of the scenarios for which 
the vendor private extension was created.  You categorically cannot add mandatory
protocol mechanisms that cause, by your own admission, such "problematic" scenarios.


> >You may argue that the component should never be too busy to handle purge protocol - but
> >remember, purge protocol is only an optimization.  Consequently, it may come after
> >forwarding related functions in component priorities (forwarding being the component's
> >main purpose in life).  This could be particularly true if the component is obliged to
> >acknowledge every purge it processes (even those that no longer apply) - as opposed to
> >simply scanning it for applicability.  A bogged down component might need to acknowledge
> >many purge messages before receiving the one that fixes the cause of its busy-ness.
> >
> >Faced with this dilemma, an implemention may "decide" to postpone (i.e. temporarily
> >discontinue) acknowledging purges while it scans each one coming in looking for specific
> >applicability.  In this case, re-sending all of the unacknowledged purges contributes to
> >the problem rather than to its solution.
> 
> After the holding time expires, the server will stop sending Purges.
> How many re-transmissions do you think a server will send before the
> holding time expires?

Based on your previous argument, "a long holding timer", the answer is 
quite a few just when extra traffic is highly undesirable!

Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    Ascom Nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]