Re: Purge packet - questions

[Andrew Smith <[e-mail]>]

> Date: Wed, 25 Oct 95 22:09:32 EDT
> From: [e-mail]
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> Subject: Purge packet - questions

Russell,

> Less control traffic, quantity of state data, more rapid convergence,
> a more flexible purge feature, etc.

Can you be a little more precise with your reasoning? The quantity of state
and rapid convergence are assertions made with no argument to back them up. A
"more flexible purge feature": what is that good for?

> >>>3. A client now *must* index by destination (match on wildcarded destination
> >>>to be more exact) and cannot use request-id for acting on the purge. Correct?
> >>
> >> True, if the request-id in the Purge is zero.
> >> The client must have a match on both the
> >> destination and request-id if the request-id is non-zero.
> 
> >Do all wildcard Purges will contain zero request-id?  (I've still not
> >seen any text from you describing the semantics of wildcard purge).

??

> >Do you think that any reduction in control packets outweighs the
> >(potential) extra processing involved in doing a wildcard destination
> >lookup rather than a request-id lookup?  

??

> >Do you think that you will
> >often have one NHS being able to coalesce multiple purges together
> >back to the same requester - can you describe a scenario where that is
> >likely?
> 
> Yes, The preferred route to a particular network changes requiring a
> refresh of the cached data.  The NHS can send multiple Purge packets for
> all destinations belonging to this network that are cached;  Or with
> a mask, the NHS can send a single Purge packet with the associated
> network mask...

Not quite: even with a mask, the NHS sends a wildcard-purge back *to each
requester* that has current cached info: you can only wildcard/summarise
the targets, not the original requesters with your proposal. 

If you assume a client-server sort of model with the clients being the 
first ones to do the requesting and there being many more clients than 
servers, then it is really the clients' addresses that need wildcarding: 
wildcarding the servers' purges does not buy you that much in this 
scenario as there will usually be a small number of servers represented
by any one NHS. Were you assuming much more of a peer-peer deployment?

I think that an analysis at this level of detail is needed in order to
judge the tradeoffs of protocol/implementation complexity vs. savings and
I haven't yet seen that done for this feature.

> >> I would expect intermediate nodes that have cache entries that match
> >> the Purge destination/mask would purge those entries.
> 
> >...and remember which way(s) to forward the Purge:  it has to be
> >forwarded back along the same path that the original response messages
> >went, rather than the current routing path, doesn't it?  It is
> >precisely when routing is changing that the purges are most useful and
> >the caches in intermediate nodes most useless, right?.
> 
> This intermdiate node subject applies to both Purges with or without
> a mask.  Correct?

Yes, but I think the processing done by each NHS doing caching is different in 
each case (is NHS caching still allowed in current revision? I know MPOA talked 
about asking to remove it for some cases) and would probably lead to a
different way of indexing the cache:

The state in question for each destination cached by an NHS is something like:
       { requester, responder, destination, hop-who-I-forwarded-response-to, 
            hold-down-time, timestamp }

When processing an incoming wildcard-purge, the NHS needs to lookup the
destination to find all matching entries and mark them all as purged.

Forwarding of the purge is not so simple: what if the "hop-who-I-forwarded-
response-to" fields are different for two destinations covered by the purge? 
Do I try to split the purge into 2 or punch holes in the mask? Do I just give 
up and forward 'n' individual purges back? Now add QoS to the database destination 
lookup too - this quickly gets out of hand. What if the purge matches
destinations for some QoSs but not others? Can you wildcard the QoS field 
too? Do I have to purge for *all* QoSs? There will be serious interactions
with QoS-based routing protocols here (sorry, I keep forgetting, there is
no such thing as QoS-based routing yet .... :-).

The issues are the same as for the "destination mask" in the Request/Response
packets. Some of the MPOA group locked itself in a room for 2 long days
last month to try to work this one out and generated a lot of heat on this
topic but very little light. One alternative would be to just put it in
and see if it works by trial and error ....

> Since the purge feature has been added, let's do it right.  Maybe
> it was a mistake to add the purge feature to NHRP ???

I thought purge was not a "feature" but a necessary part of the protocol
in order to make it work.


Andrew

********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************