[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Caching TLS connections (XSTOPTLS) Victor Duchovni Thu Jun 25 12:00:47 2009

On Thu, Jun 25, 2009 at 02:07:46PM -0400, Wietse Venema wrote:

> > > Can you quantify the gains, in terms of of long-distance network
> > > roundtrips? Assuming that the DNS lookup is cached on-site, the
> > > gain would be the TCP-level handshake.  What else?
> > 
> > Connection caching is not about saving round-trips, it is about
> > overcoming adverse (orders of magnitude higher) latency when
> > k of N MX hosts are down and non-responsive (30s timeout vs.
> > sub-second TCP 3-way handshake latency when the host is up).
> > 
> > Caching connections allows one to avoid new connection creation, which
> > involves unpredictable latency. The alternative could be a negative
> > cache for dead MX hosts with a life-time comparable to the connection
> > re-use time (300s).
> An alternative is for the scache daemon to have an option to retain
> "these hosts are good" meta-data for a couple seconds. With this,
> the discovery problem is sidestepped, and non-TLS connections may
> benefit, too.

The problem with "these hosts are good", is that one does not necessarily
know all the hosts that are good, and don't want to pile all the
connection onto the first one discovered to be good, so I think the
cache would have to be a "these hosts are bad" cache, and the lifetime
of this would cache would have to be commensurate with the connect +
HELO timeouts so that we don't have dead host connection attractors
(just as with the descriptor cache total re-use time policy).

With that, yes indeed the need to actually cache connections is reduced,
because the main benefit is not avoiding TCP 3-way handshakes RTT, but
rather avoiding TCP 1-way SYN -> eventual timeout when the destination
is a black-hole.