ACK of register and purge packets

[[e-mail]]

I propose adding an "acknowledgement request" flag in the Purge request.
There are environments/configurations where acknowledgments are
beneficial, and I agree with you that there are other
environments/configurations where it is not beneficial.

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

If the purge protocol is only an optimization, then it should be
optional (an extension).  I do not see any words in the draft that
define the purge protocol to be only an optimization.  If the holding
time is relatively long, a purge with ack is more than an
optimization.

After the holding time expires, the server will stop re-transmitting
the Purge.

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

This is one of the reaons we need the purge mask, to reduce the number
of purge messages in both directions.  Have we reached a consensus on
the purge mask?

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

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

>
>How do YOU spell superfluous?
>>
>>David.
>
>
>							Eric Gray

Have a nice day!
-- Russell