KDC query client performance

[Roland C. Dowdeswell]

On Sun, Feb 13, 2011 at 04:52:24PM -0500, ghudson at MIT.EDU wrote:
>

> 2. Speeding up the client retry loop, so that it doesn't take as long
> to time out when you're behind a firewall which black-holes port 88.
> Currently we wait one second per UDP address per pass (and per TCP
> address on the first pass), and also wait 2s/4s/8s/16s (or 30s in
> total) at the end of each pass.
> 
> In order to be nice to KDC load, I think it's still prudent to wait
> one second per server address on the first pass.  After that we're
> mostly trying to be nice to the network, and networks have gotten much
> faster.  So I think once we reach the end of the first pass, we ought
> to speed everything up by a factor of ten--that is, wait only 100ms
> between UDP queries on the second and later passes, and wait
> 200ms/400ms/800ms/1600ms at the end of passes.

It might be an idea to make the intrakdc delay be configurable.
In certain environments, one can be pretty sure of the maximum
delay you are going to experience and tune this appropriately.
Although, it might be one too many knobs.

To deal with firewalls that block UDP, perhaps the right answer
might not be to serially try all of the KDCs over UDP and failover
to TCP but rather interleave the requests in some fashion.  This
would reduce the delay in discovery of UDP issues.

Also, it might be a better idea in the longer term to write a little
daemon that runs as root, listens on a UNIX domain socket and
accepts requests from the krb5 libs to have conversations with
various KDCs.  The advantage of this would be that this daemon
could keep track of which KDCs are up and perhaps even keep track
of which ones answer the quickest (and are therefore likely the
closest), etc.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/