Re: ACK of register and purge packets

[James Luciani <[e-mail]>]

David
> David,
> 
> > 
> > Eric,
> > 
> > > >
> > > > It seems to me that the purge can/will be used to remove cache entries that
> > > > could cause routing loops (in router-router case), or an invalid path (in
> > > > the host-router case), when routing outside the cloud changes. A reliable
> > > > purge is very important for these cases. Therefore I recommmend keeping
> > > > the Purge ack.
> > > >
> > > > David.
> > >
> > >       I think that you missed the point (maybe?); because of the scenario in
> > > which a purge is not sent as a result of a component failure (crash), a
> > > "reliable purge" is an unattainable goal.
> > > This reduces the purge protocol to the status of "optimization" and it no longer
> > > makes sense to require purge originators to repeat purge messages until they are
> > > acknowledged.
> > 
> > This is a general argument that also applies to any other protocol that
> > uses Ack/Retx. Your are not suggesting that if it is possible that a network
> > componenet that has to wait for an acknowledgment ever goes down, then Acks/Retx
> > as a protocol mechanism should never be used?
> >
> 
> Hmmm...  Looks to me like a bear trap but, what the heck, guess I'll stick my foot in it
> anyways.  Certainly there are scenerios where a steady stream of messages looking for an
> acknowledgement can pose a significant threat to a component's ability to recover from a
> trauma which - coincidentally - initially precipitated the need for the messages.
SSSSSSSSSNNNNNNNNNNNNNAAAAAAAAAAAAAAPPPPPPPPPPPPP!

> > >As one member pointed out, that makes
> > > the case where a component is being taken off-line much simpler to handle as it is
> > > not necessary for the component to wait for acknowledgement before continuing the
> > > power-down sequence (this could be critical for devices equiped with short-term
> > > back-up power provided for the express purpose of allowing for a graceful power-
> > > down). If it is not necessary to repeat purge messages until acknowledged, then an
> > > acknowledgement becomes superfluous.
> > 
> > I disagree. Acks are useful to speed up convergence.
> 
> I disagree (as well). Purge protocol speeds up convergence; acknowledgements MAY help.

Eric's comment is true IMHO as well.

> >                                       However this does not make Acks
> > superfluous.
> >
> 
> 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.  
> 
> 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.
> 
> How do YOU spell superfluous?

Given when a purge is likely to be sent,  e.g., during a topological change,
it seems ill advised to me to dedicate the resources to acknowledge a protocol
mechanism which is simply an optimization.  Even if I were to have an acknowledgement
on a purge, it would be the very last thing to which I would attend during
such an occurance as topological change and I certainly would not keep a station
up to attend to it in such an event.  Remember that you have a timer
waiting on that acknowledgement and timer pops are usually (not always) high
priority events.  When that timer pops and grabs the cpu, I am very likely
to just drop the event rather than dedicate resources to it during such a major
network occurance.

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