Payload Size that can be sent in Single Shot

[Nikhil Komalan]

Hello,

I would like to know what is the maximum payload size that i can send in a single shot over thread network ?

[Jonathan Hui]

Thread supports the IPv6 minimum MTU of 1280 bytes, which includes the IPv6 header and everything encapsulated within.

--

Jonathan Hui

On Wed, Jul 7, 2021 at 12:41 AM Nikhil Komalan <nkoma...@gmail.com> wrote:

Hello,

I would like to know what is the maximum payload size that i can send in a single shot over thread network ?

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ccc0ed49-4c5e-42e3-9fb4-88bba862aebdn%40googlegroups.com.

[Nikhil Komalan]

So by using MQTT-SN in my application layer, I can send atleast 4KB of data in my payload.

Is that correct?

[Jonathan Hui]

4KB is more than what can fit in 1280 bytes. MQTT-SN does not implement fragmentation, as fas as I know. You would have to break your data up into multiple chunks.

--

Jonathan Hui

--

--

Jonathan Hui

[Nikhil Komalan]

Okay. 

So 4 times 1KB of data would be perfect with MQTT MQTT-SN ?

[Jonathan Hui]

That could work. There is a tradeoff between large packet sizes and reliability of delivering the message. You'll have to play with what works best for your application.

--

Jonathan Hui

[Achim Kraus]

Hi Nikhil,

> Thread supports the IPv6 minimum MTU of 1280 bytes

Even if that states a minimum, that's also the maximum, you can rely on.

> So by using MQTT-SN in my application layer, I can send atleast 4KB of
> data in my payload.

You can even "send" much more, but it's very uncertain, that the other
peers "receive" it :-). So, no, about 1K is usually the limit.

Basically, the idea to use UDP for IoT is the consideration, that the
traffic is in reasonable times "spontaneous/event triggered" and
requires only small data. Beside of FOTA or "Sensor histories" that
matches at least my experience.

The last open point for me seems, if open-thread can really handle 1k
efficiently. I'm not in the details, but the wireless stuff usually have
ideas as "slots" and with that it may be, that the 1k requires more than
1 slot and will therefore be delayed by waiting for the next free slots.
So, I'm not sure if the 1k is efficient in open thread.

best regards
Achim


Am 08.07.21 um 03:44 schrieb Nikhil Komalan:

> So by using MQTT-SN in my application layer, I can send atleast 4KB of
> data in my payload.
>
> Is that correct?
>
> On Thu, Jul 8, 2021, 01:39 Jonathan Hui <jon...@google.com
> <mailto:jon...@google.com>> wrote:
>
> Thread supports the IPv6 minimum MTU of 1280 bytes, which includes
> the IPv6 header and everything encapsulated within.
>
> --
> Jonathan Hui
>
>
>
> On Wed, Jul 7, 2021 at 12:41 AM Nikhil Komalan <nkoma...@gmail.com
> <mailto:nkoma...@gmail.com>> wrote:
>
> Hello,
>
> I would like to know what is the maximum payload size that i can
> send in a single shot over thread network ?
>
> --
> You received this message because you are subscribed to the
> Google Groups "openthread-users" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> openthread-use...@googlegroups.com

> <mailto:openthread-use...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/openthread-users/ccc0ed49-4c5e-42e3-9fb4-88bba862aebdn%40googlegroups.com

> <https://groups.google.com/d/msgid/openthread-users/ccc0ed49-4c5e-42e3-9fb4-88bba862aebdn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "openthread-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openthread-use...@googlegroups.com

> <mailto:openthread-use...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openthread-users/CACfSCcuC351pQOWO7D9%3DU8KkX2nnNhygUrKAopCb1urc%3DXzC3A%40mail.gmail.com
> <https://groups.google.com/d/msgid/openthread-users/CACfSCcuC351pQOWO7D9%3DU8KkX2nnNhygUrKAopCb1urc%3DXzC3A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Nikhil Komalan]

Okay thanks for info

[Nikhil Komalan]

Okay. So will FOTA over UDP a good idea ? 

[Jonathan Hui]

On Wed, Jul 7, 2021 at 10:37 PM Achim Kraus <achim...@gmx.net> wrote:

 > Thread supports the IPv6 minimum MTU of 1280 bytes

Even if that states a minimum, that's also the maximum, you can rely on.

Yes, for clarification, IPv6 requires supporting a minimum of 1280 bytes to be compliant. At the same time, Thread specifies 1280 as the IPv6 MTU.

The last open point for me seems, if open-thread can really handle 1k
efficiently. I'm not in the details, but the wireless stuff usually have
ideas as "slots" and with that it may be, that the 1k requires more than
1 slot and will therefore be delayed by waiting for the next free slots.
So, I'm not sure if the 1k is efficient in open thread.

Thread specifies a CSMA/CA MAC and does not use slots or time synchronization. That said, Thread's IEEE 802.15.4-based MAC has a 127 byte MAC MTU, so larger IPv6 datagrams will be fragmented across multiple IEEE 802.15.4 frames.

--

Jonathan Hui

[Jonathan Hui]

Communicating bulk data over UDP is certainly achievable and often used in production, but you have to understand the limits of UDP (datagram-based, no flow control, no congestion control, etc.).

--

Jonathan Hui

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/e8c8ac9c-95e1-49f4-a778-55755146de67n%40googlegroups.com.

[Achim Kraus]

Hi,

> Thread specifies a CSMA/CA MAC and does not use slots or time
> synchronization. That said, Thread's IEEE 802.15.4-based MAC has a 127
> byte MAC MTU, so larger IPv6 datagrams will be fragmented across
> multiple IEEE 802.15.4 frames.

Thanks!

So, if there is less traffic, 10x127 will take 10 times the 127?
Or are there additional times between the fragments?
If there is a lot of traffic and therefore more collisions, how long
does it then take in practice?
Something as 12x?
Or more/less?
Not known/tested?

best regards
Achim


Am 08.07.21 um 20:13 schrieb Jonathan Hui:

[Achim Kraus]

Hi,

> Okay. So will FOTA over UDP a good idea ?

that depends on a lot of other factors.

Generally the current comparisons say more or less using TCP is more
efficient (e.g.
https://github.com/eclipse/leshan/wiki/Using-CoAP-Block-Wise-to-transfer-large-file-%3F).
But that requires TCP running at all.
And sometimes the comparison is base on using a fast and reliable
connection.

For UDP, e.g. RFC7959 (CoAP blockwise) the assumptions are more or less
a slower, and maybe not that reliable, connection. And the very most
implementations stick to NSTART-1 (means, always only 1 exchange in
flight). That adds all the RTTs up to a long download time.

FMPOV, this comparison-result is more based on the current
implementations than really on the technology fundamentals.
I guess, adapting CoAP blockwise to NSTART-2 (or 4) will result in large
performance gains, also over unreliable connections. But for now, I'm
not aware, that someone is working on improving the UDP (e.g.
blockwise-like) stuff in that direction (e.g.
https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ improves
blockwise, but targets to other use-cases, not FOTA).

best regards
Achim

[Jonathan Hui]

On Thu, Jul 8, 2021 at 1:18 PM Achim Kraus <achim...@gmx.net> wrote:

 > Thread specifies a CSMA/CA MAC and does not use slots or time
 > synchronization. That said, Thread's IEEE 802.15.4-based MAC has a 127
 > byte MAC MTU, so larger IPv6 datagrams will be fragmented across
 > multiple IEEE 802.15.4 frames.

So, if there is less traffic, 10x127 will take 10 times the 127?
Or are there additional times between the fragments?

IEEE 802.15.4 specifies the transmission procedure with CSMA/CA. Each transmission includes a random backoff, clear-channel assessment (CCA), data frame transmission, and ACK frame reception.

 

If there is a lot of traffic and therefore more collisions, how long
does it then take in practice?
Something as 12x?
Or more/less?
Not known/tested?

That depends how much contention there is. CSMA/CA uses a random backoff for media access, so it largely depends on when the device is able to acquire the media and successfully receive an ACK.

--

Jonathan Hui

[Nikhil Komalan]

Hello,

Currently i am only able to publish payload length of 1K bytes in single shot (excluding additional MQTT-SN  info to form a MQTT-SN packet). 

So i would like to know the reason why my payload size isn't exceeding 1K bytes.

[Nikhil Komalan]

Also i want to know If i want to send 2KB of data in single shot is it possible or not ?

[Jonathan Hui]

The maximum IPv6 datagram size Thread supports is 1280 bytes (including the IPv6 header and IPv6 payload).

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/f545dd8f-0c57-4a6a-8026-bb5dcc4ed3dbn%40googlegroups.com.