> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker 
> <nore...@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.

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.

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


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


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

Ack, will do.

DW


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to