How big is the DTLS 1.2 CID message header for CoAP messages?

[RoryL]

I'm using the Cloud Multi-Service app on nRF9160 to test the CoAP DTLS 1.2 CID support while connected to nRF Cloud to evaluate, and want to check the data size for messages sent to help estimate total data use over time. In coap_client.c I can see the size of the CoAP message layer sent and received, but I need to know how big the underlying DTLS overheads are.

1) In DTLS 1.2. CID - How big is the CID used by the nRF SDK 2.6.1 + Modem v1.3.6?

2) Using AT%XCONNSTAT to help check the message overheads for a CoAP POST (after DTLS has already connected)

Using AT%XCONNSTAT? to check the modem states (with AT%XCONNSTAT=1 just before temperature data sent) returns:

%XCONNSTAT: 0,0,0,0,139,97 - where: max_packet = 139, min_packet = 97

Where the coap POST (confirmable) len = 51 (for header_len=12(token=8), options len=11, data len=28).

Does this mean the total data pkt overhead = 139 - 51 = 88 bytes for this POST? And 97 bytes is the size for the Coap Ack (including overheads) ?

3) After a Google search on DTLS overheads - I had expected total data overheads for DTLS 1.2 CID + UDP/IP to be approx = ~57 bytes if CID length is say 16 bytes long.

Assuming IP(20) + UDP(8) + DTLS(13) + CID (16) = 57.  So I'm not sure if the results from XCONNSTAT implies a much bigger CID length is being used?

In conclusion - Can you please confirm the actual data overheads for DTLS 1.2 CID with nRF SDK. This will be very helpful for estimating data use over time

[Achim Kraus]

> IP(20) + UDP(8) + DTLS(13) + CID (16)

If you want to "save" data, I would not use a 16 bytes CID (but that's the server's configuration, e.g. "coap.nrfcloud.com" uses 10 bytes).

The DTLS 1.2 CID record does not only add the DTLS 1.2 header with the CID, it also adds the explicit part of the "nonce" (usually 8 bytes) and 8, 16, 32 or <what ever> bytes MAC (depending on the negotiated cipher suite). There is also some CoAP header (variable, depending on the options as path or query or), therefore, overall, I usually consider 100 bytes overhead per message (that includes then also the handshake). e2e security isn't for free. e.g. the "explicit nonce" is used to ensure, that the same data doesn't result in the same encrypted message. The MAC is used, to protect the appl. layer (e.g. CoAP) from "noise by an attacker". Other techniques may come with an other balance here, but that usually only effects applications, which are using very small application messages.

To be frank, in my cases, I more afraid, that a MVNO disables my SIM because of the very low usage than in a too expensive bill for the extra 100 bytes.

[Achim Kraus]

Just in the case you want "exact numbers" for your case, using a modem trace, cellular monitor and wireshark will show the data usage in your case.

[RoryL]

Thank you Achim,

That's all good information to know (I didn't find CID=10 for nRF Cloud in my search of the docs).

The total DTLS 1.2 CID overheads are bigger than I expected, but they're not a deal breaker. My concern with data overheads was to help me understand the expected total data use per day for our use-cases. It can add up fast with multiple POST/Acks and GET/responses per day, but still much more efficient than MQTT (without the need  for pings)

My question about what's reported in the %XCONNSTAT response in (2) and (3) above is still relevant. From your answer it seems to me the max_packet length could be for the whole payload (including DTLS/UDP overheads, given it's 88 bytes bigger than the CoAP payload). But in my previous MQTT testing with the same nRF Cloud Multi-Service app I found the max_packet lengths reported exactly matched the total MQTT payload (without the TLS/TCP overheads).

So I'm still interested to hear what the modem includes in the max_packet and min_packet lengths for  %XCONNSTAT - does it include the total DTLS/UDP overheads, but not the TLS/TCP overheads?

[Achim Kraus]

> %XCONNSTAT

I'm only a community member (and expert for CoAP / DTLS).

In my UDP experience, it matches all parts, from the IP-header up to the payload.

If %XCONNSTAT reports different numbers for UDP or TCP then I guess someone from Nordic will know the reason and may answer this.

[Achim Kraus]

> (I didn't find CID=10 for nRF Cloud in my search of the docs).

I got that with Wireshark from the Server_Hello.

[Achim Kraus]

> The total DTLS 1.2 CID overheads are bigger than I expected, but they're not a deal breaker.

For DTLS 1.2 it's pretty much the same as TLS 1.2. The bytes saved in the TLS header are then spend more in the TCP header.

The overall saving comes from the reduced number of handshakes. How much that is depends then more from the communication pattern. If you send something every 5 minutes, you may not need it. But to save energy I guess sending every 60 min (and on events) will be the better approach. If sending every 24h (and on events) does match the requirements depends mainly in the required "fail safe". Frequent messages also indicate the system health, and missing ones may start the "fail safe procedure"., what ever that is. 

Beside of the data volume savings, in my experience CoAP/DTLS 1.2 CID is more reliable than TCP based stuff. Even if Nordic still sometimes write, that TCP will be slightly better, that's not my experience and I'm still open for an competition to see, what the "wild" will really show.

As an example from an Thingy:91

179-22:26:04 [d-hh:mm:ss], Thingy:91 v0.9.0+0, 0*4499, 1*48, 2*0, 3*0, failures 4
!3873 mV 63% (358 days left) battery
!CE: down: 8, up: 1, RSRP: -95 dBm, CINR: 12 dB, SNR: 13 dB

180 days, about 4500 messages, some retransmissions, 1%% failures.

github.com/.../zephyr-coaps-client

[Charlie]

Achim Kraus said:

If %XCONNSTAT reports different numbers for UDP or TCP then I guess someone from Nordic will know the reason and may answer this.

Thanks for the active helping in Devzone. I can confirm %XCONNSTAT statics cover all data running through IP protocol, which is also the data usage count by the network operators.

[RoryL]

Thank you Charlie - that's good to know that it covers all IP data sent and received (for UDP and TCP).
I must have mis-calculated the message lengths with my previous MQTT testing.

Regards, Rory