On Mon, Sep 12, 2016 at 09:02:15AM +0000, Daniel Margolis wrote:
> Viktor, I certainly agree that that's a *reasonable* ballpark number, based
> on my experience. But I still have a slightly odd feeling about specifying
> *specific* numbers in the spec for the reasons I gave.
The problem with not giving any specific guidance, is that server
operators no longer know what latency metric they are to be measured
by. If a particular server takes 3 seconds to respond, but a client
times out after 2 seconds, which one is out of spec? Is the server
under-provisioned, or is the client timing out prematurely?
You said that Postfix timeouts are shorter than RFC 5321, but this
is not the case, you've confused the TCP connection timeout (30s)
with the command timeouts from RFC5321, which in Postfix are in
fact as specified:
$ postconf -d | grep '^smtp_.*_timeout = ' # output reordered and FPs
pruned
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.1
smtp_starttls_timeout = 300s
smtp_xforward_timeout = 300s
smtp_mail_timeout = 300s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.2
smtp_rcpt_timeout = 300s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.3
smtp_data_init_timeout = 120s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.4
smtp_data_xfer_timeout = 180s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.5
smtp_data_done_timeout = 600s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6
smtp_quit_timeout = 300s
smtp_rset_timeout = 20s
$ postconf -d smtpd_timeout
smtpd_timeout = ${stress?{10}:{300}}s #
https://tools.ietf.org/html/rfc5321#section-4.5.3.2.7
(The server timeout for idle client connectiosn is temporarily
reduced to 10s while and for a short time after the SMTP server
connection count is maxed out, i.e. the server is under "stress").
The TCP 3-way handshake timeout is not specified in RFC5321, and
the O/S default TCP connect timeout is much too long on multiple
platforms, so Postfix uses 30s as still generous, but more reasonable
bound.
Perhaps with HTTP timeouts are so much less of an issue than with
SMTP, that setting clear expectations is not a requirement? My
guess is that some sort of "contract" would be helpful.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
