Hi Duane! See inline. > On 28. Aug 2021, at 00:44, Wessels, Duane <dwessels=40verisign.com@xxxxxxxxxxxxxx> wrote: > > > >> 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. 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
