Cache Thrashing (review by Y. Rekhter)

[wmhaddad@…]

Cache thrashing by hosts within a site results in sending packets to a large span of addresses and create a huge amount of LISP control traffic.

[luigi@…]

Authors replied on the mailinglist that in their opinion there is no need to make any change to the draft. Neither the original person that raised the issue nor the mailinglist stated a different opinion.

[yakov@…]

The issue raised in this ticket has to be addresses. Until it is addressed, the ticket should stay open.

[yakov@…]

From the response to the ticket:

Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors
have reviewed your comments but do not feel that changes to the document are
warranted at this time. We feel that existing text adequately describes cache
management behavior.

The response is insufficient, as it fails to point out to the specific section(s) of the existing text that according to the authors "adequately describes cache management behavior". In order to determine whether the existing text is adequate, the first thing the authors need to do is to point out to such text.

[jmh@…]

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.

[yakov@…]

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.