Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

[Achim Kraus]

Knowing, that the AS-RAI implementation is experimental, I would still prefer to have more documentation about the details.

I already asked for these details in an other issue (see Details of AS-RAI and CP-RAI fallback ) but for me there are still some gaps.

The above referred thread discussed, that requesting to use Rel. 14 AS-RAI, the modem falls back to Rel. 13 CP_RAI, if AS-RAI isn't supported by the network provider. So far, so good. The nasty point seems to be, that you can't use this fallback without knowing that, because the supported options seems to differ for AS-RAI and CP-RAI and a function to see, that the modem decided to fall back, is missing.

My results (the trace are provided in the referred thread):

With Rel. 14 AS-RAI only the SO_RAI_NO_DATA seems to work, with SO_RAI_ONE_RESP I had no success.

With requesting Rel. 14 AS-RAI, but fallback to Rel. 13 CP-RAI, SO_RAI_NO_DATA doesn't work, but SO_RAI_ONE_RESP is now working.

My questions:

1. Please document, which options are working in which mode (SO_RAI_NO_DATA, SO_RAI_LAST, SO_RAI_ONE_RESP combined with Rel. 14 AS-RAI, AS-RAI fallback to CP-RAI).

2. Is it possible the check, if the modem falls back to Rel. 13 CP-RAI? Especially, if the first question shows, that there are no common supported options, such a function helps to implement a working application.

Thanks in advance. 

[dejans]

Hi,

I have asked internally. I will get back to you by Monday next week at the latest.

Best regards,
Dejan

[Achim Kraus]

Thanks!

Also for the answers in the other discussion.

[Achim Kraus]

To mention what works and what works not in the documentation would have saved a lot of time, at least for me.

In my opinion it is not "the best possible way" to swallow a SO_RAI_ONE_RESP or SO_RAI_NO_DATA in the case it is not supported. Either returning an error code or the actual RAI mode supported by the network would enable users to write better applications and understand the network features.

[Michal Mühlpachr]

Achim Kraus said:

In my opinion it is not "the best possible way" to swallow a SO_RAI_ONE_RESP or SO_RAI_NO_DATA in the case it is not supported. Either returning an error code

Error code would trigger AT command flow redesign for Serial LTE Modem application since there is no easy way to distinguish breaking/non-breaking error. I understand, that for API level it is not an issue, but a feasible solution should consider broader use cases than just API.

[Achim Kraus]

> Serial LTE Modem

That's one application among a lot.

> there is no easy way to distinguish breaking/non-breaking error

I assume, you mean at the AT-cmd level of that application?

AS-RAI uses "setsockopt", which already defines to return errors. The current implementation actually returns error codes, e.g. if the UDP socket is not connected, you get a -1 and errno of 121 (EDESTADDRREQ) for SO_RAI_NO_DATA. Returning an error in cases, where the selected RAI option is not supported by the network is more a bugfix according the expected behavior then an API break.

I don't use the "Serial LTE Modem", so if other feel, that an error causes trouble there, then it should be very easy to swallow a returned error in that application.

[Michal Mühlpachr]

Achim Kraus said:

I assume, you mean at the AT-cmd level of that application?

Yes.

Achim Kraus said:

I don't use the "Serial LTE Modem", so if other feel, that an error causes trouble there, then it should be very easy to swallow a returned error in that application.

SLM returns just OK or ERROR. In case of ERROR it would not be clear if it is a breaking error (e.g. socket is not connected) or a non-breaking error like a feature is not supported by the network.

So there would not be an easy way how to distinguish whether to swallow or not swallow error.

[Achim Kraus]

That affects only SLM. And for that it's very easy, to keep the wrong OK, even if setsockopt returns an error.

But to return error, if something doesn't work as expected, is for me a well API designed. And that fix should not be blocked by a single application.

I guess you request a different API. Without an alternative proposals, I don't see, that this would be available soon. But return an error for setsockopt should be not too hard, even if SLM will then not benefit.

[Michal Mühlpachr]

Achim Kraus said:

But to return error, if something doesn't work as expected, is for me a well API designed. And that fix should not be blocked by a single application.

I agree, but socket API does not have that general quality and so such an approach would require wider API redesign.

E.g. if you send UDP packet using socket API, you will not get an error in all cases, when the packet was not sent by the device.

Overloading socket API by passing signalization regarding L2 Link Layer over L3 Network Layer API is not a good approach.

Socket API insufficiency is also the reason, why you are asking for notifications about packets actually sent.
But there is a catch, because there could be more than one UDP packet sent (on the way in modem), so you would need to identify to what exact packet is a notification about packets actually sent related.
And there is not any packet id that could be used for that.

Achim Kraus said:

I guess you request a different API.

Yes, because there is a mix of layers in one API (socket API overloading).

SO_RAI_* is Link layer related, SO_SILENCE_ALL is also not related to UDP or TCP either, etc.

The current socket API is also the reason, why there is no reasonable way, how to provide the information required for bulk transfer timing implementation - power consumption optimized congestion control.

[Achim Kraus]

> I agree, but socket API does not have that general quality and so such an approach would require wider API redesign.

Yes, it has some flaws. They are caused by a compromise not to block calls for an actual later outcome. But that seems to be more common. I'm not sure, if the modem's "nrf specific socket" API returns errors on poll, but on other implementations that works.

The point with a "redesign" would be the timeline. I would guess, it will take that long, that for many it will never come ;-). And I still miss an alternative proposal.

> why you are asking for notifications about packets actually sent.

No, I don't ask. I tired to explain, why RRC idle will not help for your bulk transfer. But for now I don't plan to use a bulk-transfer over UDP. In other cases/systems, using "poll" with POLLOUT does the job, but I don't know, if that is implemented in the "nrf socket". Maybe, once in the future, I would try to switch NSTART-2 or 4 for a coap blockwise FOTA, but not for now and not with more pending messages as a small couple.

So all in all:

Without an alternative proposal I don't see, that a discussion about the weakness and flaws helps. At least in my awareness quite a lot are common to that and will benefit from the error codes more then they suffer from things, which are not working with that approach.

[Michal Mühlpachr]

Achim Kraus said:

In other cases/systems, using "poll" with POLLOUT does the job

In other systems (e.g. Linux) you get only info regarding socket buffer (SOCK_DGRAM in case of UDP) is ready for another send with poll/POLLOUT, but that is not info regarding datagram was actually sent.

DGRAM socket API is not suitable for link layer control.

Achim Kraus said:

Without an alternative proposal I don't see, that a discussion about the weakness and flaws helps.

It helps to make clear what are the flaws and what is missing. In other words, what should be handled by extended API.

One option can be to add LTE link layer API (it could be made also with socket approach by adding special socket type aka LTE link layer or just add special LTE link layer API exposing all LTE under the hood details) and bring control, status info, events, data transport capabilities there.

It would not break the current higher-level TCP/UDP API and it will bring lower link-level control to applications, that can implement energy-efficient data transport.

[Achim Kraus]

> in other systems (e.g. Linux) you get only info regarding socket buffer (SOCK_DGRAM in case of UDP) is ready for another send with poll/POLLOUT, but that is not info regarding datagram was actually sent.

In my experience from other systems, that helps a lot for congestion control. It prevents the system from dropping messages internally. I don't know, if that is implemented by the modems socket implementation. Unfortunately, such stuff is missing in the documentation.

> One option can be to add LTE link layer API

My impression about such extensions and redesigns is more, that they don't happen. At least not without a huge commercial project requesting it. Therefore, as I wrote, I would be happy if it starts with reporting errors, even if that has also still some drawbacks.

I guess, even a more complete documentation will take several weeks. And I don't see, that a redesign will happen this year. An error code may have a better chance.

[Michal Mühlpachr]

Achim Kraus said:

In my experience from other systems, that helps a lot for congestion control. It prevents the system from dropping messages internally.

Of course, but it does not address all states.

Achim Kraus said:

An error code may have a better chance.

Does queue based socket API layer have any insight into immediate link layer properties?

It is not a good API pattern to intermix queue and immediate approach in one API.