Re: ACK of register and purge packets

[Eric Gray <[e-mail]>]

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.

> 
> >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.

>                                                       In some cases an
> ACK does not make it (e.g., above scenario or a catastrophic failure),
> and the protocol needs to handle it.

Not the scenerio referred to; in some cases, the PURGE does not make it and the protocol
needs to handle it.  WHAT this means is that - regardless of how busy a router (or route
server) might be, it MUST 1) progress the aging of its cache entries and 2) observe the
expiry of same.  This is required because it is the only reliable mechanism available to
ensure that invalid entries are (eventually) removed. Consider that a route(-serve)r may
be consuming nearly all of its resources in activities related to forwarding traffic in
a loop.

>                                       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?

> 
> David.


							Eric Gray