NSTART Not Implemented

[janvinas]

Hello,

I've noticed that the NSTART parameter has no effect, and CON requests always wait for the previous request ACK to arrive before being transmitted. Setting Message.transport_tuning.NSTART to a different value than 1 does not change this behavior.

Are there plans to implement this feature in the library?

Thanks.

[chrysn]

Generally I'd be happy to help adding this; I just have little time to do that actively before summer for personal reasons.

One question that we'll have to ask to add this is how it is determined, as CoAP-over-UDP's good behavior across the Internet hinges on its very conservative NSTART and PROBING_RATE parameters. (And the two proposals for tuning CoAP's properties there, COCOA and FASOR, are both quite stuck).

• In a LAN or an otherwise controlled network that doesn't route across the Internet, this would be fine to tune.
• For Internet-wide use, I'd prefer to have a protocol in place that provides some back-off mechanism to avoid congestion.

Which of those would your applications fall into? (Just as to avoid us starting on this, only to find out later why NSTART is as it is).

[chrysn]

Marked as bug and enhancment because that NSTART is editable gives a wrong impression (that'd be fixed by documenting that NSTART is not respected when changed), and beyond that, aiocoap could be enhanced to really use it.

[janvinas]

I'm testing COAP on a very sparse LEO satellite network, where satellites and ground stations do store-and-forward. When there's a transmission opportunity (the satellite is visible from the device), there might be more than one CON message waiting to be transmitted and, with NSTART=1, the device can transmit only one of them. The satellite stores the message until it can be transmitted to a ground station and routed through the internet to the server, and the reverse happens with the response. Therefore, the response can take a time in the order of hours to reach the client, during which no more interactions can be initiated.

I don't know what kind of congestion control mechanism could be used in this scenario, or if it is feasible at all. Maybe the easiest solution would be to design my application in a way that multiple messages can be aggregated in the same payload and transmitted in a single CON message, and using NON messages whenever possible.