Subject: Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Sep 2021 16:23:47 +0000

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> 
> 
> 
> First a minor comment here:
> "TCP connection timeout, which is often around 60-120 seconds."
> I guess this value relates to an RTO of 1s and 6 SYN retries which is the
> default in Linux. Maybe say that...? I also recommend to add a link to RFC6298.

I've made this addition to the paragraph in section 4.1:

   ... rather than
   rely on the host operating system's TCP connection timeout, which is
   often around 60-120 seconds (i.e., due to an initial retransmission
   timeout of 1 second, the exponential back off rules of [RFC6298], and
   a limit of six retries as is the default in Linux).

> 
> And a more general comment on section 4.2: this section takes about various
> limits but doesn't recommend any values. I understand that there is not a
> one-fits-all solution here but not knowing how to set these values correctly
> might scared people aways from supporting TCP. So I think having a discussion
> either of default values or how to derives these values based on a certain
> configuration would be a very valuable contribution in this document.

I've added some recommendations to the paragraphs in section 4.2.

For the limit on total number of connections: "Absent any other information,
150 is a reasonable value for this limit in most cases."

For the limit on connections per source address: "Absent any other
information, 25 is a reasonable value for this limit in most cases."

For the timeout on idle connections: "Absent any other information, 10
seconds is a reasonable value for this timeout in most cases."

> 
> Similarly section 4.3 talks about tuning net.ipv4.tcp_fin_timeout, however, it
> doesn't provide any guidance on how to tune it; Linux recommend a value of
> 15-30 seconds. Also setting net.ipv4.tcp_fin_timeout to a too low value and
> net.ipv4.tcp_tw_reuse to 1 can cause trouble and should not be done for the
> general case. So I don't think that guidance is appropriate without further
> discussion of the risks. Please reconsider this part of the document!

This paragraph in section 4.3 has been rewritten:

   On systems where large numbers of sockets in TIME_WAIT are observed
   (either as client or server), and are affecting an application's
   performance, it may be tempting to tune local TCP parameters.  For
   example, the Linux kernel has a "sysctl" parameter named
   net.ipv4.tcp_tw_reuse which allows connections in the TIME_WAIT state
   to be reused in specific circumstances.  Note, however, this affects
   only outgoing (client) connections and has no impact on servers.  In
   most cases it is NOT RECOMMENDED to change parameters related to the
   TIME_WAIT state.  It should only be done by those with detailed
   knowledge of both TCP and the affected application.

> On section 4.4, maybe mention TCP fast open here again as well?
> 

It now reads:

   Unoptimized connection
   setup takes two additional round-trips compared to TCP, but can be
   reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS
   False Start [RFC7918].

FYI We're tracking these changes in github at https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/5 if that is helpful.

DW

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 7 Sep 2021 18:42:58 +0200

Thanks for the updates! One quick comment below.

> On 7. Sep 2021, at 18:23, Wessels, Duane <[email-masked]> wrote:
> 
> 
> 

I think it would also make sense to explain a bit more why these values were taken and what considerations/“other information" can be used to make a different decisions. I know that might not be fully straight-forward but just providing “random” numbers might also only provide limited value.

Mirja

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 17 Sep 2021 19:46:45 +0000

> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

Mirja,

I have gathered some information from the open source implementations and written a new section to talk about defaults and recommended values (below).  The full document and diff from previous can be found in our github repo https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/tree/master/Versions

DW

4.5.  Defaults and Recommended Limits

   A survey of features and defults was conducted for popular open
   source DNS server implementations at the time of writing.  This
   section documents those defaults and makes recommendations for
   configurable limits that can be used in the absence of any other
   information.  Any recommended values in this document are only
   intended as a starting point for administrators that are unsure what
   sorts of limits might be reasonable.  Operators SHOULD use
   application-specific monitoring, system logs, and system monitoring
   tools to gauge whether their service is operating within or exceeding
   these limits, and adjust accordingly.

   Most open sorcue DNS server implementations provide a configurable
   limit on the total number of established connections.  Default values
   range from 20 to 150.  In most cases, where the majority of queries
   take place over UDP, 150 is a reasonable limit.  For services or
   enviroments where most queries take place over TCP or TLS, 5000 is a
   more appropriate limit.

   Only some open source implementations provide a way to limit the
   number of connections per source IP address or subnet, but the
   default is to have no limit.  For environments or situations where it
   may be neccessary to enable this limit, 25 connections per source IP
   address is a reasonable starting point.  The limit should be
   increased when aggregated by subnet, or for services where most
   queries take place over TCP or TLS.

   Most open source implementations provide a configurable idle timeout
   on connections.  Default values range from 2 to 30 seconds.  In most
   cases, 10 seconds is a reasonable default for this limit.  Longer
   timeouts improve connection reuse, but busy servers may need to use a
   lower limit.

   Only some open source implementations provide a way to limit the
   number of transactions per connection, but the default is to have no
   limit.  This document does not offer advice on particular values for
   such a limit.

   Only some open source implementations provide a way to limit the
   duration of connection, but the default is to have no limit.  This
   document does not offer advice on particular values for such a limit.