[GitHub] [mynewt-nimble] paulreimer opened a new issue #398: Feature Request: Mesh Proxy Message, Configurable Segmentation Strategy

[GitBox <gi...@apache.org>]

paulreimer opened a new issue #398: Feature Request: Mesh Proxy Message, Configurable Segmentation Strategy
URL: https://github.com/apache/mynewt-nimble/issues/398
 
 
   There are two segmentation strategies described in the Mesh Profile (one of them generic, one of them only applicable to the GATT Proxy service):
   - `Segment`s in the Lower Transport Layer
   - `SAR` as used in the proxy GATT service (6.3.2 in the Mesh Profile spec)
   
   Currently in NimBLE it seems that Lower Transport Layer segmentation happens first, independently followed by Proxy Service SAR (if necessary). This presents a few issues:
   1. Sending even a single large message requires increasing `BT_MESH_TX_SDU_MAX` to accommodate the whole mesh stack for this largest possible size. (Even if the large message is only sent proxy node->GATT client and could use SAR)
   2. Sending GATT proxy messages larger than `BT_MESH_TX_SDU_MAX` is [not permitted](https://github.com/apache/mynewt-nimble/blob/7be23d325293345858d3123975f7193311a7ea04/nimble/host/mesh/src/access.c#L634), as the possibility of SAR is not checked.
   3. SAR is a more efficient use of the transport -- it can handle larger byte sizes and variable MTUs, with less overhead (fewer # of packets, fewer # of bytes, as well as fewer crypto operations).
   
   I would like to be able to at least hint/specify that SAR should be preferred when sending a message, and ideally automagically have the ideal segmentation strategy used for any given payload.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services