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

From: Aditya Chopra <[email-masked]>
Date: Tue, 29 Mar 2011 12:26:23 -0700

People rise to their level of incompetence - way to go Yakov "Peter
Principle" Rekhter!! Love the Cisco-Juniper war, somebody else can then
steal the pie.

------ Forwarded Message
From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 10:14:18 -0700
To: <[email-masked]>, <[email-masked]>, <
[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter)

Hi,

> #46: Cache Thrashing (review by Y. Rekhter)
>
> Changes (by jmh@â•œ):
>
>   * status:  reopened => resolved
>   * resolution:  => fixed
>
>
> Comment:
>
>  Text has been added to the -11 revision of teh specification noting that
>  cache thrashing happens, that implementors should think about it, and
that
>  the experiment may tell us more about whether this is an issue needing
>  further attention.

Here is the text that has been added:

   Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance is an issue to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.

The above text failed to mention that cache sizing is an issue not
just "during implementation", but during deployment as well.

Moreover, the above text failed to mention that in the context of
LISP, thrashing of the cache on a given ITR/PTR has non-local
implications, as it could result in excessive volume of LISP control
traffic, which in turn would further deteriorate the situation.

Finally, the above failed to mention that being able to
detect thrasing is necessary, but not sufficient - an implementation
must be able to suppress thrasing.

With all this in mind I would like to propose replacing the text
quoted above with the following:

   Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance is an issue to be kept in mind
   during both implementation and deployment. In the context of
   LISP, cache thrasing on the ITR/PTR could result in the ITR/PTR
   dropping data, thus negatively affecting connectivity. Moreover,
   it could also result in excessive volume of LISP control traffic,
   which could spread the detrimental effects of thrasing beyond
   the ITR/PTR and all the hosts that communicate through this
   ITR/PTR. Therefore, an implementation MUST provide instrumentation
   in place to detect thrashing of the cache, and MUST provide
   mechanism(s) to suppress thrasing.  Specifications of such
   mechanisms are outside the scope of this document.  Implementation
   experimentation will be used to determine which cache management
   strategies work best.

Yakov.

> --
-------------------------------+--------------------------------------------
> Reporter:  wmhaddad@â•œ          |        Owner:
>     Type:  technical           |       Status:  resolved
> Priority:  major               |    Component:  draft-ietf-lisp
> Severity:  -                   |   Resolution:  fixed
> Keywords:                      |
>
-------------------------------+--------------------------------------------
>
> Ticket URL: <https://wiki.tools.ietf.org/wg/lisp/trac/ticket/46#comment:6>
> lisp <http://tools.ietf.org/lisp/>
> LISP WG document issues
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

------ End of Forwarded Message