Registration Message Flow

[jpradocueva]

It can happen that the Client receives a request (Read or Write operations) before the registration is completed, (it received 2.01 Created response).

How should the client respond?
What the Server should expect?

Due to UDP re-ordering this can happen any time.
A time out or backoff could cause problems with the sleep mode of the Client.

Expected behaviour must be defined in the TS.

[boaks]

Using a separate CON response (see rfc 7252, 5.2.2) and waiting for that ACK of the response may ensure, that the client received the registration response.

Piggyback flow (currently normally used, rfc7252, 5.2.1):

1. LwM2M Client sends request as CON with MID1
2. LwM2M Server sends response as ACK (piggyback) with MID1

After sending the reponse, the LwM2M server has no information about the client receiving the response.

Separate flow (rfc 7252, 5.2.2):

1. LwM2M Client sends request as CON with MID1
2. LwM2M Server sends ACK with MID1
3. LwM2M Server sends response as CON with MID2
4. LwM2M Client sends ACK with MID2

Waiting for the the ACK from the LwM2M Client the server may ensure, that the responses is received from the LwM2M client.

[jvermillard]

@boaks after reading the spec I don't think it's mandatory to wait for the end of registration for accepting read/write on the DM interface. Would that cause a problem? or maybe I'm misunderstanding the spec.

[boaks]

@jvermillard
My proposal was just a solution for the case that somehow the registration must be finished before using the DM interface.
If the TS defines the expected behaviour in a way, that the client should accept request after sending the registration, this is OK for me.
In some rare case we may find issues when the communication of multiple registers and DM request overlap. But right now, I don't think they are serious. (e.g.: a different client registers from a reused ip-address and receives old request intented for the other old client of that ip-address.)

[jvermillard]

It bother me to use seperate ack/response for register because it make the whole process heavier and longer (I count bytes on cellular networks or SMS) so I prefer to keep it like that.

Do you think we can close this issue? or do you want some spec clarification?

[boaks]

From my view, this issue was opend because of different incompatible implementations.
Therefore the TS should just clarify the wanted behaviour, in which way ever.

[boaks]

Do you think we can close this issue?

I think, though I haven't report this issue, I'm not the one to close it :-).

[ThGarnier]

According to comments => to be closed

[boaks]

Just for those, who read issues later:
Would it be possible to "close" with a reference to the LWM2M TS, which clarifies the behaviour?

And to be frank: I just don't see a clarification, how a LWM2M client should react on device management operations before it receives the answer from the registration. Please keep in mind, that message order is not granted in UDP. A server which sends the ACK and short afterwards a Request (e.g. READ) is not able to ensure the receiving order of the client. If the order is wanted, a separate response is required. if the order is undefined, the specification should clarify the processing, if the order has changed!

[sbernard31]

The last OMA-TS-LightweightM2M-V1_0-20161031-D said :
"The LWM2M Client MUST ignore the LWM2M Server operation on this interface until it received its Registration acknowledgement."
"The LWM2M Server MUST NOT perform any operation on this interface until the registration of this LWM2M Client completed."

So it seems that now separate response is mandatory for Register Request.
But I don't understand which kind of problem we try to fix with this new constraint ?

[dnav]

I fail to see how this mandates a separate response. The problem fixed by this is issue #162.

Regards

[sbernard31]

It depends on what means "The LWM2M Server MUST NOT perform any operation on this interface until the registration of this LWM2M Client completed."

I understand it as "the server must not send any request until the client receive the response". So, If the server need to know the response is well received, it must used a confirmable separate response.

Am I wrong ?

[dnav]

The intended meaning was : "the server must not send any request before sending the ack to the registration message."
Furthermore if the server receives the registration message again, it must consider the other requests it may have sent as lost.

[sbernard31]

As message order is not granted in UDP, I'm not sure to understand why we want to be sure that server will send the ack before the read (#162).

[msangoi]

I agree with @sbernard31, this new sentence about the server behaviour is quite unclear:

The LWM2M Server MUST NOT perform any operation on this interface until the registration of this LWM2M Client completed.

If the client ignores the commands received before the registration ack, it seems to me that relying on the retransmission mechanism is enough to ensure the messages order.
If this is the expected behaviour, the above sentence is clearly confusing.

[dnav]

Noted.
We will try to come up with a better sentence.

[sbernard31]

Thx David :)
I think removing the second sentence is enough.

[Megan-OMA]

Closing issue per agreement above and no further comments since 11/2016