Does CoAP allow multiple oustanding (ACKed) CON Requests when NSTART is 1

Question

According to the CoAP RFC, NSTART is a limit on the number of outstanding interactions. But it describes an outstanding interaction as:

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)

This would seem to imply that if an empty ACK has been received for a CON request, but the matching response has not yet been received, it is okay to send a new CON request (with a different token of course) without violating NSTART=1. Is this interpretation correct?

Answer 1

I received a response from the IETF core mailing list, confirming that NSTART is not a constraint on the number of concurrent, ACK'd CON requests:

Does this wording imply that concurrent CON requests (ACK'ed, but for which a CON response is still expected) are acceptable if NSTART=1?

Yes.

If an empty ACK has been received for a CON request, may a new CON request be sent before a CON response has been received for the first request, without violating the NSTART=1 constraint?

Yes.

The idea is that the fact that the CON did receive an ACK (and the latency taken for that) indicates that the path is not heavily suggested, or that the necessary slow-down has been achieved (by the original RTT, and by wait times before retransmission).

The server will independently congestion-control their separate responses.

Answer 2

In my memory, it's years ago, that we had such discussions about that. First at all, if you really want a qualified answer, please try the core-mailing-list or create an issue in Corrections and Clarifications

For me, NSTART-1 play mainly a role in congestion control. So the very first question will be, if your devices, server, or network is rather constrained? If you violate the NSTART-1 in a constraint use-case, you will get more drops and so also more retries and that results in more inefficiency.

If NSTART-1 sticks now to a "constrained transmission layer" or a "constrained application layer", may give you the answer. If it's the transmission layer, you don't want to overload that. That means, you only have one exchange in flight. And you not only wait for the ACK, you also wait for the response, otherwise a new request may cross the response and results in overload. But that are all just assumption. In many cases neither the network-layer nor the application-layer is that constrained and with that, you may also relax that from one open "request-response-exchange" to one open "con/ack". Finally, if you implement and server, don't force NSTART-1, that makes in my experience more trouble than it helps.