On Sun, Sep 11, 2016 at 11:56:55AM +0000, Daniel Margolis wrote:
> So this sort of makes me think that we should not bother to suggest
> specific timeouts in the RFC, as I am not sure how useful they will be.
> (Now, granted, the world has changed since RFC 2821 was written; it's
> hardly a sign of failure if 15 years later your timeouts aren't quite the
> norm!)
>
> Any contrary opinions on this? And if so, any specific thoughts on what
> those timeouts should be?
I, for one, would like some guidance.
I know what to expect in the SMTP space, where with Sendmail, Qmail,
Postfix or Exim each connection consumes considerable resources,
and MTA listeners can fall behind the connection rate under high
load. Even if the TCP 3-way handshake completes, a busy MTA might
not return a 220 banner immediately (reverse DNS lookup latency or
just not enough resources to immediately accept the connection).
(The Postfix "connect" timeout is not only the timeout for completing
the TCP handshake, but is also overloaded as the timeout for the
220 banner).
I am not sure what to expect with HTTPS. Guidance on the timeouts
would not only help senders to avoid unreasonably aggressive short
timeouts, but may guide receiving systems in selecting an HTTPS
server with appropriate response characteristics.
My instinct is that with (typically) non-forking HTTPS servers,
much higher connection concurrency can be sustained than with
SMTP, and that responses will likely exhibit much lower latency
(in large part because no reverse DNS lookups take place, but
also because HTTP servers are generally scalable to very high
connection counts).
So my sense is that ~5s is about right for a (1 RTT) TCP connection
(assuming both peers are on Earth). Any suggestions about the TLS
handshake? What's a reasonable minimum time-out for that? Unlike
TCP TLS can be 2 RTTs for a full handshake, and TLS requires some
CPU on the server. Returning the policy in response to the HTTP
request should be quite fast, so perhaps 5s is generous enough for
that?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
