Hello Yoshi, Sorry for the late reply, and thanks a lot for taking the time for your review and for providing comments.
Please find below my inline responses: > Hello, > > I've read the draft and I think the draft looks fine and mostly ready. > I have some comments below.. > > 1: Section 4.2.4: > "In that case, RTO algorithm tuning may be considered, although > careful assessment of possible drawbacks is recommended" > > -> It might be better if we refer draft-ietf-tcpm-rto-consider here > although it is not very certain the draft will be published at this > moment? It seems to me the motivation of the doc fits the situation > like this. I agree. I guess we may cite draft-ietf-tcpm-rto-consider as an informative reference for this section. > 2: Section 4.3.1: > "These algorithms work efficiently for window size of at least 5 MSS" > > -> Just curious why this is 5? Is it because the use of delayed ack is > presumed? > A receiver may have a chance to send an ack for segment 1 before > segment 3 arrives. Yes, the text was written under the assumption that delayed ACKs might be in place. In the next revision we will explicitly indicate the assumption, and update the related text as per your comment. > 3: Section 5.3 > CCN -> CNN? Thanks for catching the typo! > "This overhead could be reduced by TCP Fast Open (TFO)" > > -> Yes, but the use of TLS is not mandatory in this draft. If an > implementation utilizes TFO, we might want to mention about app level > idempotency here. Not sure I'm following you here. Could you please elaborate? > "TCP keep-alive messages are not very useful to..." > > -> We don't need to discuss reducing the interval of keep-alive here? Currently, we have some text on this, although I agree it is a bit too indirect. In the next revision, we will elaborate further. Once again, thanks for your comments. Cheers, Carles > Thanks, > -- > Yoshi _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
