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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 25 Aug 2021 08:51:54 -0700

Reviewer: Mirja Kühlewind
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Thanks for the well-written document! I have a couple of points below regarding
the recommend TCP tuning in section 4. Other parts of the document don't seem
to have any transport issues and are clear to me.

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.

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.

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!

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

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 27 Aug 2021 22:44:00 +0000

> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 

Hello Mirja,

Thanks for the review.  I haven't had a chance yet to discuss with my
coauthor, John, so these are just my own thoughts at this point.

> default in Linux. Maybe say that...? I also recommend to add a link to RFC6298.

Yes suppose it does relate to RTO and SYN retry values, although I'm not
too sure how much those details matter to the intended audience of this
document (DNS software operators).  It says "60-120 seconds" just based
on general experience of how long connection timeouts usually take, without
understanding the inner workings of TCP.

I searched a little for something we could cite to support the 60-120 seconds
statement, but didn't really find anything.  If you think we should use RFC 6298
and the values from Linux to support that, then I guess its fine.

> configuration would be a very valuable contribution in this document.

Do you think it would suffice to provide a range of recommended values?
I think we'd have to go back to the working group to get consensus.

Alternatively, are you suggesting to document what defaults are in current
implementations?

> discussion of the risks. Please reconsider this part of the document!

I see your concern.  Would it be okay if we say here that these are for
experts only?  e.g. the sysctl values should only be changed by someone
that has detailed understanding of how TCP works and really understands
the consequences of tweaking them?

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

Ack, will do.

DW

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 28 Aug 2021 11:07:12 +0200

Hi Duane!

See inline.

> On 28. Aug 2021, at 00:44, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
> 
> 

The point is these values are roughly right at the moment but behaviour can change, so explaining where this comes from is more future-safe.
> and the values from Linux to support that, then I guess its fine.

Yes, sounds good.

> Alternatively, are you suggesting to document what defaults are in current

Both is fine. As you said recommending values probably needs more discussion and maybe also more input from TCP experts. I guess you could also reach out to the tcpm mailing list.
 
> the consequences of tweaking them?

You really need detailed knowledge about TCP and the application as well. I would maybe even be more careful and discuss that these configurations exists and explain a bit more what they do but by default don’t recommend to change, expcet it’s checked that the application will benefit. 

Mirja

> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art