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

From: [email-masked] (Noel Chiappa)
Date: Mon, 4 Apr 2011 11:01:08 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

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

This mostly all looks fine, but I still don't get the wishy-washy
"specific management mechanisms are beyond the scope of this
specification". Despite my repeatedly asking on the list, nobody has
mentioned any solution to this (very real) potential problem other than
the time-honoured 'have a large enough cache'.

Sure, we don't have to mandate that as _the_ solution (so if someone has some
brilliant 'better mousetrap', they should feel free to go for it), but if it's
the only one a group of very knowledgeable engineers/designers knows of, it's
professional malfeasance (IMO) not to explicitly refer to that solution.

	Noel

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 4 Apr 2011 08:21:26 -0700

Noel,

> brilliant 'better mousetrap', they should feel free to go for it), but if 
> it's the only one a group of very knowledgeable engineers/designers knows 
> of, it's professional malfeasance (IMO) not to explicitly refer to that 
> solution.

How about the following modification of the text I proposed in my previous 
e-mail (the change is in the last sentence):

  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. While the specific management mechanisms are beyond 
  the scope of this specification, we would like to note that one
  such possible mechanism would be to increase the cache size.

Yakov.

---

From: Srinivas Subramanian <[email-masked]>
Date: Mon, 04 Apr 2011 13:04:05 -0700

>   such possible mechanism would be to increase the cache size.

Another possible mechanism for undersized caches on ITRs - when an ITR
detects that its cache has hit a high water mark, then it could install a
coarse (catch all) entry and encapsulate data to a PETR. The PETR would
decapsulate the traffic from the ITR and if it is also a PITR, it could
re-encapsulate the traffic to the remote ETR using the EID-to-RLOC mappings
in its cache. 

This might increase the stretch for data but would decrease the excessive
control traffic and avoid the data traffic drops on the ITR caused by the
excessive cache churn.

-Srin

> 
> Yakov.
>   
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp