Re: [core] Typical TCP segment header size for CoAP over TCP

[Achim Kraus <[e-mail]>]

Hi Carsten,
Hi John,

proposing to add the udp/tcp headers was not done on order to have a
precise prediction of resulting traffic. It's done to have the DTLS
and TLS comparison more in balance. If DTLS requires 8 bytes more than
TLS, but TCP 12 bytes more than UDP, both variants are very close.
So that just doesn't make the difference.

If additional protocol messages are "injected" (e.g. TCP ACKs), then the
change of the number of bytes, is in my experience not that relevant.
Here it's more the number of resulting messages or flights.
For UDP some of that functions are also pushed to upper layers and would
then need to be considered there as well, e.g. CoAP ACKS for "CoAP
separate response". Never ending.

An next aspect would then be the additional messages for "connect".
TCP messages, (D)TLS handshakes and so on. That requires then a model,
how often that happens. Even more never ending.

My preference here would be to focus on the overhead of the application
data. And therefore that table is pretty well. Just add the udp/tcp
headers and it gets clear, that there is no big win nor loss.

My proposal for a "overall" statistic:
Better try to collect that data for that statistic with demos.

Here my contribution with CoAP/DTLS 1.2 CID:
https://github.com/boaks/zephyr-coaps-client

114-23:54:04 [d-hh:mm:ss], Thingy:91 v0.5.99, 0*2649, 1*109, 2*2, 3*0,
failures 1
3940 mV 66% battery (low-power)
Stat: tx 1384kB, rx 186kB, max 539B, avg 290B, searchs 176, PSM delays 0




best regards
Achim

Am 21.01.23 um 15:53 schrieb Carsten Bormann:
> On 2023-01-21, at 15:44, Achim Kraus <[e-mail]> wrote:
>>
>> So 20 bytes.
>
> RFC 9006 notes that some TCP options (SACK, Timestamps) may not bring their full benefit to constrained environments, but may still be useful.
>
> E.g. [1]:
>
>     If a device with less severe memory and processing constraints can
>     afford advertising a TCP window size of several MSSs, it makes sense
>     to support the SACK option to improve performance.
>
>
> So the question really is which TCP options are in wide use in constrained environments.
>
> 20 bytes of course is the baseline value (for data packets; I’d expect MSS [2] to be in most SYN packets of implementations that consider IPv4).
>
> Grüße, Carsten
>
> [1]: https://www.rfc-editor.org/rfc/rfc9006#name-selective-acknowledgments-s
> [2]: https://www.rfc-editor.org/rfc/rfc9006#name-maximum-segment-size-mss