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

[Mirja Kuehlewind <[e-mail]>]

Thanks for the updates! One quick comment below.

> On 7. Sep 2021, at 18:23, Wessels, Duane <[e-mail]> wrote:
> 
> 
> 
>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <[e-mail]> 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
>