Thanks for the updates! One quick comment below. > On 7. Sep 2021, at 18:23, Wessels, Duane <dwessels@xxxxxxxxxxxx> wrote: > > > >> 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." 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 > > >> >> 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 > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
