Performance and Replay Cache

[Steve Edgar]

In the early 90s, a basic client/server protocol was developed at  
Cornell called Cornell University Stateless Server Protocol (CUSSP).   
Each request from the client contains a K4 ticket for  
authentication.  The contents of each request are encrypted with  
mk_priv.

This protocol is still used on a few servers.  One of these servers  
commonly sees an incoming request rate of 35 requests per second.   
After converting CUSSP to use K5, the increase in latency resulting  
from the replay cache affects performance.

If the replay cache is not used, K5 latency is low; about that of K4  
latency.  A search on the krbdev mail list archives mentions some  
applications do not need the replay cache, but I think ours needs the  
replay cache.  Can someone comment on under which circumstances the  
replay cache need not be used?

Also from reading previous posts, I noticed some folks have mentioned  
the possibility of using a memory based replay cache as opposed to a  
disk based replay cache.  The risk with that being no replay cache is  
available immediately after a server restart.  Has anyone used a  
memory based replay cache, and if so did you see a big increase in  
performance?

Is a significant increase in performance for a disk based replay  
cache possible via an alternative implementation?  That is, could  
changes or optimizations to that code improve its speed?  If so, we  
may have someone here at Cornell who could investigate and contribute.

-- Steve.