I’ll chime in with my two cents as well.
Totally depends on your application - how often you send data back, how often you need to sleep the modem, how often you expect to lost connectivity, etc.
Major factors in overhead are that Particle’s protocol requires 6KB each time the modem connects to the cell network, as well as a 122 byte ping packet every 23min. This is not part of the UDP standard, but seems to be something custom that they’ve implemented on top of UDP to establish and maintain a session that guarantees delivery, reliability, and security (all of which UDP inherently lacks). Like @benstr mentioned above - if you plan on sending lots of tiny messages over short intervals, and don’t plan on losing your cellular connection very often, this is probably the solution for you.
- Session setup/maintenance overhead: 6KB + 122 bytes every 23min
- Additional overhead per message: 126 bytes
Our own Hologrammer @ross wrote up a little article that touches on our TCP overhead here: https://medium.com/hologram-io/hologram-io-data-usage-breakdown-3fc48f7a24c8#.k891ue12j
Basically, you can expect around 500 bytes of TCP overhead per message, and that’s it, because the session is reestablished each time you send. This is optimal for applications that don’t send data back as often, or are unable to maintain a consistent cellular connection for whatever reason (need to sleep the modem, cell carrier connection resets, lose cellular service, etc.)
- Overhead per message: 500 bytes
In regards to strategies for lessening the amount of data used - we basically have a lot of the same suggestions as in Particle’s documentation:
- Use shorter names when labeling data
- Combine multiple messages into a single bulk message
- Incorporate data logic on your device and optimize the data being sent back
If none of these work for you, we happily offer our Ublox passthrough firmware so that you can mess around with AT commands on the Ublox yourself and develop your own optimized protocol. Ways to send AT commands to Ublox!
We realize that raw AT commands are a bit of a burden to work with though, so within the next month or so, we will be open sourcing our Dash firmware so that people can more easily develop solutions for their more targeted use cases. Stay tuned!
I hope I was able to answer your questions - if not, feel free to reach out!