> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker <noreply@xxxxxxxx> 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>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call