TCP packet size

[kmfnjtze8888]

Hello,

What is the maximum size for each packet sent via TCP?

From the code, the maximum size of the TCP receive buffer is OT_TCP_RECEIVE_BUFFER_SIZE_FEW_HOPS = 2599, but each packet is broken down on average around 462 bytes. However, sometimes it goes over that (e.g., 715 byte packet), so I'm just wondering where the max TCP packet size is defined. Thank you!

[samkumar]

Hi @kmfnjtze8888, thanks for your interest in TCP.

The maximum segment size is defined at https://github.com/openthread/openthread/blob/main/third_party/tcplp/bsdtcp/tcp_const.h#L54. It is calculated assuming a target of 5 frames per TCP segment (that's why FRAMECAP_6LOWPAN is set to 5). In that code, MSS_6LOWPAN is set to 474; the actual amount of data in each outgoing packet comes out to 462 bytes because 12 bytes are lost due to the TCP timestamp option.

If you wish to tune this value, I would recommend first reading Section 6.1 of the TCPlp paper, which explains how the current MSS of 5 frames was chosen. In high-interference environments, it may make sense to reduce the MSS to 3 frames, which can be done by setting FRAMECAP_6LOWPAN to 3. However, I would not recommend increasing the MSS beyond 5 frames, as the gains in doing so are very limited (see Figure 3 in the paper).

The TCP implementation may deliver data to the application in odd-sized chunks on occasion, due to multiple data-containing TCP segments being received before the application reads the data. Could this be what you observed with 715-byte packets? The actual data-containing TCP segments sent over the air should never be that big.

[kmfnjtze8888]

Hi Sam,

Thank you for answering my question!

I do not wish to to tune the MSS_6LOWPAN value, so I just specified the size of the receive buffer of the TCP endpoint during initialization (i.e., tcp init 488). I am mainly trying to keep the size of each packet to be less than 488 due to buffer size constraints in my firmware. Would this cause problems?

Also, regarding buffer sizes, OT_TCP_RECEIVE_BUFFER_SIZE_FEW_HOPS is chosen by default, and it is recommended to choose OT_TCP_RECEIVE_BUFFER_SIZE_MANY_HOPS for 6 or more hops. But if I expect for example, more than 15 hops, would I need to increase the buffer size even more?

[samkumar]

If you're trying to keep each individual packet small (less than 488 bytes), then you don't need to tune anything, as the default MSS is less than that value.

If you're trying to keep the total data in the receive buffer small, then what you said would work. Making the receive buffer small (488 bytes) would affect performance, as it limits the total number of packets that are simultaneously in-flight. Making the receive buffer smaller than the MSS would also limit the size of individual packets, as a side effect.

You're right that, over a very large number of hops, you may need to increase the buffer size beyond OT_TCP_RECEIVE_BUFFER_SIZE_MANY_HOPS. However, I don't think this is a common use case for Thread --- I think it would be very rare for a network in someone's home to span 6 hops or more.

[samkumar]

I just realized that I might have misunderstood what you mean. If you have the memory to buffer more than 488 bytes, but can only consume 488 bytes at a time, the best way to handle that is a bit different. You can keep the receive buffer at the recommended value, and only consume data when there are 488 bytes to read. Any bytes you don't consume will remain in the receive buffer, and can be consumed later.

In general, the only reason I can think of to reduce the receive buffer size is a lack of RAM, and the only reason I can think of to reduce the packet size is if you have reason to expect higher frame loss. If the limitation is just that your firmware can process only 488 bytes at a time, then you should use the approach I mentioned above and not try to tune the packet size.