Overhead in sending messages over LTE-M
-
I'm sending a payload of exactly 1585 Bytes, using a POST to a server, using the urequests.py library. On the dashboard of my LTE-M provider is shows that the total data transfer for this message is 8kB. Now I know there is some overhead involved in TCP/IP, but here it goes from roughly 2 k to 8 k so that is a lot. A suggestion from the provider is that maybe the modem has a low MTU (Maximum Transmission Unit) so the message is split in many small chunks and then transmitted, each chunk with it's own overhead.
Could be, but how can I find out what MTU is used in Sequans modem (or maybe this is done in the socket library) ? And does anyone even know a way to set this ?
-
@jcaron Thanks for testing this. It seems indeed the most likely conclusion, certainly if the handshaking itself is already over 5000 bytes.
-
@Cees_Meijer The initial handshake can involve quite a bit of data, remember one or more certificates will be included, each one being a few hundred bytes.
Wireshark should definitely show the details, you just won't see the contents of the TLS request, but you'll definitely see IP, TCP, and TLS information.
I just make a quick test with Wireshark and openssl s_client and got 5945 bytes with no payload at all. The exact value will depend on the length of the certificate chain, the size of the certificates, and what exactly is counted. You should also add a little bit for DNS, and of course your payload and MQTT overhead. So 8 KB seems quite consistent with that.
From a desktop browser you would have session caching for subsequent requests, but I'm not sure that is implemented here (nor that it would actually work if you only have one TLS session once in a while rather than a quick succession of TLS connections).
-
@jcaron : Thanks, I really did not think about the SSL part. Since I'm sending it to a https:\ , it will indeed be encoded. And it will require the SSL handshake, which will probably add some as well. I cannot really find any figures on this though. Most people are just concerned about the delay, not so much the nr of extra bytes.
I thought about analyzing the server side using WireShark, but this will probably not show me the SSL part.
-
@Cees_Meijer are you using TLS (aka SSL)? There’s a lot of overhead in TLS session establishment.
If you have control over the server try capturing the traffic with tcpdump or ethereal, that should tell you quite a bit.