> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <noreply@xxxxxxxx> 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
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
