> 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.
right - a typical system we used in 1981 was a DEC LSI/11 which had 64Kbytes of RAM for the whole OS and network stack - so the actual buffer space for packets might be a couple of kbytes - the thing is tho, that over a LFN (remember also, the backbone speeds were 56kbps, and international links might have satellites with .72 seconds RTTs), a sender still might speculatively keep more packets "in flight" than the receiver buffer advertised, if the receive processing meant that the bottleneck was always "in the air" not at the receiver of course, in a lot of CORE environments, the RTT is small enough that i think you're right, and advertising an MSS receive window would result in the stop&wait behaviour - can easily try this even on a couple of laptops on a wifi net........ maybe... int clamp= 576; setsockopt(sock, SOL_SOCKET, TCP_WINDOW_CLAMP, (char *)& clamp, sizeof(clamp)); > > 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
