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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please 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 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). Sec 4.3.3.1 s/since with SACK recovery/since SACK recovery _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
