Indications throughput vs notifications

[Tamar]

Hi,
We have latency sensitive implementation, for that usage we implement Gatt over classic server (iPhone is client, DUT is server - using gatt_streamer_server)
Using notifications I received throughput of ~140 kilobyte per second
Using indications I received throughput of ~16 kilobyte per second.

The need for using indications is to have reliability (not having data loss) which can't be achieved

1. I'd expect indications to be around 50-70~kilobyte/s. any ideas why we get such low performance and how to further optimize?

2. I thought of trying to sending data using several characteristics indications in parallel,
   when i receive acknowledgment of indication_complete, i call att_server_request_can_send_now_event but according to API we can't add user data so eventually I don't know on which characteristic I can send the packet.
   is it possible to send indications in parallel?
   Thanks in advance
   
   
   Hi, I've realized its not possible to send indications in parallel.
   The thing is I need the data to be reliable  and I can't trust notifications for being reliable...in a noisy environment I believe we can't know for sure that data will be reliable..any suggestions?

[Matthias Ringwald]

Hi Tamar

A GATT Server can only send one Indication per ATT Bearer and the reply from the GATT Client does not contain the attribute handle either.
If you need to use GATT over Classic, I would recommend to use Notifications and if there's actually an issue, add some kind of 'sliding window protocol' to keep that under control.

In general, Bluetooth does not loose packets over BR/EDR or LE. All packets are acknowledged on the link layer. There's an option to mark a packet as 'automatic flushable' which will discard outgoing packets if not sent in a fixed amount of time but BTstack doesn't use it.

In which situation did you observe GATT Notifications getting lost? Do you have HCI logs for that?

Best regards
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/a534aec0-dcbd-43d7-a823-c49af5dba21dn%40googlegroups.com.

[Tamar]

Hi,

In which situation did you observe GATT Notifications getting lost?

We did not have such situation, we just want to make sure the data will pass reliably and I know that notifications are like UDP.

If link layer acknowledges all packets, and re-transmits them, then what's actually the difference between notifications to indications? 

I know that in notify we send packets as long as controller is ready- is the meaning it received an acknowledgment for the previous packet or the meaning is that it just sent the data and the buffer it holds is empty and can be re-filled?

Thank you

[Matthias Ringwald]

Hi Tamar

Yes, Notifications are a bit like UDP in the sense that they are not acknowledged. However, they don't get lost on a single hop link over BR/EDR or LE either.

Indications require an explicit acknowledgment from the remote side. This can act as a synchronization point. Some higher level profiles explicitly use Indications to make sure a command was received.

Also, the main operations from the GATT Client are read and write. Both operations have a result message. The indications then are the equivalent to the write without response from the GATT Client.

With notifications, BTstack allows to send you as many as fit into the Bluetooth Controller which allows for max use of air time. If you're sending faster than the remote can handle it, packets might get dropped on the remote Bluetooth Host stack. In this case, you need to add some kind of sliding window protocol. I'd first test naively, e.g. sending max size packets with a counter and check if you loose any.

Alternatively: you could use L2CAP LE Credit-based channels with l2cap_cbm_... functions, but I'd try regular notifications first.

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/871197b6-5f05-4e06-89d5-e3ec8ac56f5en%40googlegroups.com.

[Matthias Ringwald]

Hi Tamar

The link layer will acknowledge all ACL packets. This makes sure the packet reaches the other side. Now, it's up to the other side/stack what happens to ti.
The GATT Indication requires the GATT Client on the remote side to send a GATT Indication Confirm back.

Cheers
Matthias

> On 19 Dec 2023, at 14:21, Tamar <tamar.v...@orcam.com> wrote:
>
> Hi,
> there's something I'm missing..
> if indications do get acknowledged in link layer but not in higher levels, then I'd assume link layer does retransmission when needed? but if I should implement window sliding protocol it means the link layer does not acknowledges indications doesn't it? otherwise it would be responsible for retransmission
>
> thanks

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/3a7db77d-d4aa-4adc-8457-b55459cf8d0bn%40googlegroups.com.

[Matthias Ringwald]

Hi Tamar

The general idea is that with Notifications, you can send packets back-to-back, while with Indications, you'll send a single packet of size ATT MTU and need to until it was received on the other side, processed and a Indication Confirm was sent back. You run two BTstack examples on the same host and have a detailed look at the packet time stamps. I guess it just adds up for the indications.

Cheers
Matthias

> On 19 Dec 2023, at 15:40, Tamar <tamar.v...@orcam.com> wrote:
>
> Also, do you maybe have an idea why would I receive such low throughput (17 kb/s) while in notifications I receive around 140 kb/s?
> i'd expect around 50~70 kb/s
> thanks

>
> On Tuesday, December 19, 2023 at 3:21:15 PM UTC+2 Tamar wrote:
> Hi,
> there's something I'm missing..
> if indications do get acknowledged in link layer but not in higher levels, then I'd assume link layer does retransmission when needed? but if I should implement window sliding protocol it means the link layer does not acknowledges indications doesn't it? otherwise it would be responsible for retransmission
>
> thanks
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/c18efd81-e65e-45ee-97e6-7c9f9f0a2d5en%40googlegroups.com.