Dear Michael, Thank you very much for your detailed comments (and sorry for the late response).
Please find below some inline responses: > 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. Agreed. We'll address this in the next draft revision. > - 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. Right, one thing to provide details about in the document is which are the available ways to enable the intended stop-and-wait operation. > - 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. Section 3.6 can be definitely updated to clarify the need to support the MSS option (options 0, 1, and 2). On the other hand, the intent of the 'MUST NOT' was to make sure that implementation complexity/memory footprint is reduced by not supporting the options mentioned in the section. Nevertheless, we can phrase this goal in a different way, more aligned with your text above. > - 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. Agreed. > - 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. The main reason motivating draft-ietf-core-coap-tcp-tls is the need to traverse middleboxes, so a primary scenario is communication between constrained devices (e.g. 'sensor nodes') and unconstrained devices over the global Internet (e.g. backend servers, etc.). I agree that the document needs to clarify and discuss the two main scenarios mentioned. > - ... (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. Thank you very much. Definitely, feedback from TCPM will be of great help and value. With regard to presenting the document, there is an unfortunate collision in Berlin, as I have requested a presentation slot (of another draft) for the 6lo WG meeting (which takes place simultaneously with tcpm). Not sure if this could be solved in some way... On the other hand, I'll (also) present this draft (draft-gomez-core-tcp...) in the lwig WG meeting. Cheers, Carles > Michael > > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
