Just out-of-curiosity: In 1981, when the current TCP spec was published, end hosts had significant processing and memory limitations. Quite a bit of the TCP protocol mechanisms were designed to deal with senders and receivers that have very small buffers, e.g., of the order of the maximum segment size.RFC 793 is very carefully designed to deal with these constraints. And current TCP implementations are still backward compatible to RFC 793.
When quickly scanning through this document, some observations (the list is not comprehensive): - TCP counts window sizes in bytes, which draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. - Out-of-my-head, nothing prevents a TCP sender from limiting the congestion window to a small window (e.g., one MSS). This basically turns TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide to limit its congestion window if it wants to simplify its implementation. I am not sure if RFC 2119 language is needed for that at all. - A TCP receiver can use the receive window to prevent the sender from sending data, e.g., if it can only deal with one MSS. It may be interesting to look into whether advertising a maximum receive window e.g. of at most one MSS would solve some of the problems discussed in the draft. - TCP options will only be enabled if supported on both ends and a standard-compliant TCP stack only has to support the MSS option (more precisely, option kinds 0, 1, and 2). An implementation that does not want to use any additional TCP features does not have to implement support any of those options. However, to be compatible with RFC 793 the option kinds 0, 1, and 2 have to be parsed in SYNs and thus basic support for option parsing in SYNs is required anyway. If the basic support for option parsing in SYNs is in place (which is not very complex code), it seems easy to process any other options that may be present in the SYN as well, and just ignore them. Thus, I do not understand what added value a MUST has that "forbids" TCP options that may typically not be negotiated in the environments addressed by this document. - If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., because it advertises very small receive window), the delayed ACKs in TCP may offer some opportunities for optimization, e.g., a receiver could want to turn them off delayed ACKs when it advertises a very small receive window. I believe the document could look into that space. - There are quite a number of differences between using TCP only inside a controlled environment, or using TCP with endpoints that are located in the Internet. I would recommend that a document explicitly discusses both variants, as design trade-offs could be different. And I would assume that one of the reasons for picking TCP would be to at least have the option of end-to-end transfers over the global Internet. - ... (there is more) In general, the TCPM list is followed by quite a number of different TCP implementers and there is some expertise on the original RFC 793 design decisions. If the intention of this document is e.g. to define up a minimum set of TCP features required for a stop-and-wait operation and with very small buffers, I'd assume that relevant expertise would be on the TCPM list. So, it might make sense to keep the TCPM list in the loop. Presenting the document in TCPM may also be an option the authors may want to think about. Michael _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
