NSTART-1 for QueueMode ?

[sbernard31]

LWM2M-v1.2@transport§6.5. Queue Mode Operation (also true for LWM2M v1.0.x and v1.1.x) says :

Due to the congestion control approach used by CoAP the LwM2M Server has to wait for a response to a request before sending out the next request from the queue since [CoAP] limits the number of simultaneous outstanding interactions to 1.

I have some question about this LWM2M specification sentence.

Before to start with question, It seems this sentence refer to NSTART=1 from rfc7252#section-4.7 :

In order not to cause congestion, clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions
that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1.

1. Why this is limited to 1 ?

NSTART is not always equals to 1. This is just the default value.

2. Why this is limited to Queue mode ?

The sentence is in "Queue Mode Operation" chapter ? why this is specific to Queue Mode chapter ?

3. Which queue ?

It says :

LwM2M Server has to wait for a response to a request before sending out the next request from the queue ...

But later in same chapter :

Despite the title of the functionality, i.e. Queue Mode, this specification does not mandate an implementation to use queues nor does it specify where such a queue would exist (or any details of such queuing mechanism)

4. Why this is limited to Server ?

The LWM2M specification seems to only talk about NSTART=1 for server.
Note that it exists a Coap Config [Id 500]) Object where we can configure NSTART at client side.

5. How does it behave with CoAP over TCP ?

rfc8323#section-1 says :

TCP utilizes mechanisms for congestion control and flow control that are more sophisticated than the default mechanisms provided by CoAP over UDP

I'm not sure but I understand that CoAP "Congestion Control" does not make so much sense with TCP, so this sentence is maybe very Coap over UDP oriented. (In a more general way the whole chapter seems to be CoAP over UDP oriented e.g. CON, ACK, MAX_TRANSMIT_WAIT does not match so well with TCP ..)