> More discussion here: > https://groups.google.com/g/nuttx/c/bh01LHix7nM/m/bL8242BQCwAJ Johnn > y is a > pretty knowledgeable guy a references a couple of other RFCs there.
Thank you for the link to the discussion. There is useful additional info: RFC 2581 (4.2) says: > Therefore, while a specific algorithm is not defined, it is desirable > for receivers to attempt to prevent this situation, for example by > acknowledging at least every second segment, regardless of size. I suppose that is why uIP (and the existing CONFIG_NET_TCP_SPLIT algorithm in NuttX) splits a full-sized segment into two smaller segments. However, RFC says "desirable", not "required". On another hand, a newer RFC 2923 (2.2) says: > How to fix Several solutions for this problem have been proposed: > > A simple solution is to ACK every other packet, regardless of size. > This has the drawback of generating large numbers of ACKs in the face > of lots of very small packets; this shows up with applications like > the X Window System. > > A slightly more complex solution would monitor the size of incoming > segments and try to determine what segment size the sender is using. > This requires slightly more state in the receiver, but has the > advantage of making receiver silly window syndrome avoidance > computations more accurate Thus it looks like we can not know and can not rely on how any arbitrary TCP/IP stack implements this. > The algorithm came from uIP 1.0 from around 2001. Might be > interesting to > see what uIP in Contiki did with that in later years. I have checked Contiki-ng git repo history. uip-split.c file was removed along with IPv4 stack from Contiki on 16- Jun-2017. Also I have checked the newest source code of Contiki-ng and I did not find anything related to TCP packet split algorithm in the currentlyused IPv6 stack of Contiki. On Thu, 2021-10-14 at 20:27 -0600, Gregory Nutt wrote: > The language in the RFC is not clear. What is a full size > packet? Is that > the MSS which could potentially vary from segment to segment > depending on > the sizes of the headers. Is that the receive window size which > could also > vary? Not clear. > > I don't think there is any general way to always send an even number > of > full-size packets... whatever that means. That is another good > reason to > remove the unbuffered send. > > The algorithm came from uIP 1.0 from around 2001. Might be > interesting to > see what uIP in Contiki did with that in later years. > > More discussion here: > https://groups.google.com/g/nuttx/c/bh01LHix7nM/m/bL8242BQCwAJ Johnn > y is a > pretty knowledgeable guy a references a couple of other RFCs there.
