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

Hi Duane!

See inline.

> On 28. Aug 2021, at 00:44, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <noreply@ietf.org> 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. 
>> 
>> Reviewer: Mirja Kühlewind
>> Review result: Ready with Issues
> 
> 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.
> 
> 
>> 
>> 
>> 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.
> 
> 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.

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.
> 
> 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.

Yes, sounds good.

> 
>> 
>> 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.
> 
> 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?

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.

> 
> 
>> 
>> 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!
> 
> 
> 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?

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

> 
> 
>> 
>> On section 4.4, maybe mention TCP fast open here again as well?
>> 
> 
> Ack, will do.
> 
> DW
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art