MshPRT 1.1 segmentation and reassambly support

[eanderlind]

Do you plan to add support for MshPRT 1.1 conformant lower transport segmentation and reassembly, which is quite different than the current MshPRF 1.0 implementation?

• interval between each transmitted segment and for transport ack
• different ACK behavior when all segments have been received (lastSegment)
• backoff behavior for retransmissions
• clarified rule for when a new segmented msg to same destination may be commenced

We note that this may also help issue #439, since we see similar behavior in App log where segmented PDU retransmissions cause cascading failures due to excessive number of msgs being injected into the network, causing timers to expire
and yet more messages being sent.

[philips77]

I'm starting vacations next Friday. I hope to release the app and library before with as much new features as possible.
I just recently found out about those changes in SAR. I need to read it and understand. So far I know that the time increment can be adjusted, not just the interval. There's also something about multicast ack. I'm not there yet.
To be honest, I think this won't make it next week. I hope to finish Remote Provisioning.

[eanderlind]

In case helpful for phasing - the new behavior in 3.5 is mandatory (with default values per 4.x) for 1.1, while the messages and two models in 4.x are optional. Enjoy the fjords!

[philips77]

I've started implementing that feature. It'll be the last feature before 4.0 release.
But I'm having hard time understanding the spec. Those 2 chapters about Segmentation and Reassembly are madness. It is also not taking mobile phones (GATT clients) into account, as we can't control the actual connection intervals.

[eanderlind]

BLE connection subrating may be a way (in future) to address GATT client latency.