Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter)

From: Yakov Rekhter <[email-masked]>
Date: Mon, 4 Apr 2011 07:30:55 -0700

Eliot,

> >>    Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
> >>    and that undersized caches could cause excessive control traffic,
> >>    implementations MUST have some form of cache management in place.
> >>    The specific management mechanisms are beyond the scope of this
> >>    specification.
> > The text you proposed above is insufficient as (a) it failed to
> > mention that undersized caches could lead to cache thrashing,
>
> Rather than use the term "cache thrashing", I chose instead to describe
> the effects of undersized caches, which is another way of saying...
> cache thrashing.  And it's a bit more descriptive.  I would also argue
> that it is important to be concise.

Ok, let's go with describing the effects of undersized caches.

> > (b) cache thrashing, in addition to excessive control traffic, 
> > could also result in dropping data (thus negatively affecting
> > connectivity),
>
> I think the above text captures this as well.

Perhaps you can point me to the specific part of the above text
that "captures this as well", and specifically describes how
undersized cache could result in dropping data.

> >  and (c) the detrimental effects of excessive 
> > control traffic due to thrashing could spread beyond the ITR/PTR
> > that experiences thrashing.
>
> Control traffic has to go somewhere, right?

"go somewhere" does not capture the fact that that the detrimental
effect is spread beyong the ITR/PTR that experiences thrashing.

> > Moreover, saying that an implementation must has "some form
> > of cache management in place" is insufficinet, as what is needed
> > is not just "some form" of cache management, but a mechanism
> > that would allow to suppress thrashing.
>
> Fair enough. 
> 
> How about the following then:
> 
>    Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
>    and that undersized caches could cause excessive control traffic,
>    implementations MUST have some form of cache management in place
>    that prevents excessive network control traffic.  The specific
>    management mechanisms are beyond the scope of this specification.
> 
> This also keeps things concise.  

That still does not capture the fact that undersized caches could
also result in dropping data (thus negatively affecting connectivity),
and that the excessive control traffic could have detrimental effect
beyond the ITR/PTR with the undersized cache. To address this how
about the following:

    Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
    undersized caches could result in dropping data (thus negatively
    affecting connectivity), and could cause excessive control traffic
    that could spread the detrimental effect of undersized caches
    beyond the ITR/PTR with the undersized cache. Therefore,
    implementations MUST have some form of cache management in place
    that prevents excessive network control traffic due to undersized
    caches. The specific management mechanisms are beyond the scope 
    of this specification.

> I also understand that others may be
> uncomfortable about a normative MUST.  I understand those concerns and
> have thrashed (cough) both ways about that myself.

Yakov.