[Prev] Thread [Next] |
[Prev] Date [Next]
Re: Caching TLS connections (XSTOPTLS)
Thu Jun 25 12:01:11 2009
On Thu, Jun 25, 2009 at 02:45:04PM -0400, Wietse Venema wrote:
> Victor Duchovni:
> > 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
> But, isn't this exactly how connection caching works? If you can
> cache connections, then you will be talking again to the same good
> hosts, all having the same MX preference.
No, because with connections, there is a finite pool of fds, and when
all are used concurrently, new connections are made, so the load
is reasonably distributed in practice.
With status caching, there is no limit on the concurrent re-use of
status data, so all the connections go to just the good hosts, unless
we treate good status as a consumable resouce in the same, but with
"fd == -1" (or equivalent), so that once descrtor-less connections
for a good host are consumed, new connections are made to some
"fairly" selected new host.
I think negative caching would be more beneficial than concurrency
bounded positive caching.
Re: Caching TLS connections (XSTOPTLS) Matthias Andree
Re: Caching TLS connections (XSTOPTLS) Rob Foehl