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 ? -
@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.
-
@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 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 for testing this. It seems indeed the most likely conclusion, certainly if the handshaking itself is already over 5000 bytes.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login