Hi Martin, Thank you very much for your review and feedback!
We just submitted revision -12, which aims at addressing the comments received from the IESG and related reviewers: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12 Please find below our inline responses: > Martin Duke has entered the following ballot position for > draft-ietf-lwig-tcp-constrained-node-networks-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In Sec 4.1.1: > > An IPv6 datagram size exceeding 1280 bytes can be avoided by setting > the TCP MSS not larger than 1220 bytes. This assumes that the remote > sender will use no TCP options, aside from possibly the MSS option, > which is only used in the initial TCP SYN packet. > > In order to accommodate unrequested TCP options that may be used by > some TCP implementations, a constrained device may advertise an MSS > smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that > it is advised for TCP implementations to consume payload space > instead of increasing datagram size when including IP or TCP options > in an IP packet to be sent [RFC6691]. Therefore, the suggestion of > advertising an MSS smaller than 1220 bytes is likely to be > overcautious and its suitability should be considered carefully. > > I would delete everything after the first sentence in this excerpt. While > RFC6691 is informational, it clarifies RFC1122, which is a standard, and > Sec 4.2.2.6 is quite clear that senders MUST consider TCP and IP option > length when sizing TCP payloads. > > Absent any evidence that there are TCP endpoints or middleboxes that are > violating RFC1122, further reducing the MSS because someone might be > violating it is excessive. As per the subsequent discussion in tcpm, we replaced the above text by the following: NEW: An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. Note that it is already a requirement that TCP implementations consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, it is not required to advertise an MSS smaller than 1220 bytes in order to accommodate TCP options. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please address the tsv review comments. Revision -12 intends to address the tsv review comments. > Sec 4.2.3 > s/Disabling Delayed ACKs at the > sender allows an immediate ACK/Disabling Delayed ACKs at the > request sender allows an immediate ACK Done. > Sec 4.3.1 > When a multiple-segment window is used, the receiver will need to > manage the reception of possible out-of-order received segments, > requiring sufficient buffer space. > > It's worth pointing out here that even a 1 MSS window should also manage > out-of-order arrival, as the sender may send multiple sub-MSS packets that > fit > in the window. (On the other hand, the receiver is free to simply drop the > out-of-order segment, thus forcing a retransmission). We added text as per your comment above. > Sec 4.3.3.1 > s/since with SACK recovery/since SACK recovery Done. Thanks, Carles (on behalf of the authors) _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
