1

How to handle Request-ID? oneM2M joint WG2 & WG3 discussion PRO Josef Blanz July 2 nd, 2014

3 Definition in TS-0001: ri: request Identifier. Example usage of request identifier includes enabling the correlation between a Request and one of the many received Responses. Issue: What should be the behaviour of a receiving CSE if multiple incoming requests use the same value of the request identifier? −Could happen when the Originator of a request repeats the request since it concluded the request got lost Problem Currently one parameter that is mandatory for each request is the request identifier

4 1.The Receiver CSE keeps track of the request identifiers already processed in the past (over some limited / reasonable range) and does not repeat already executed operations 2.The Receiver CSE does not keep track of request identifiers and always processes incoming requests as if they were new requests Both options have pros and cons that are discussed on the next slides Quite a few permutations of operations (CRUD&N) and request types are possible… need to be looked at! Options for defining the behavior Fundamentally there seem to be two options:

5 Requested Operation: CREATE (1) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) BlockingYesPRO: Avoids creation of multiple resources. Generate same response as was sent with the initial request that used the same ri CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May result in duplicate creation of resources Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

6 Requested Operation: CREATE (2) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Synch YesPRO: Avoids multiple resource/context zombies. Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May get duplicate creation of resources and request contexts => more zombies Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

7 Requested Operation: CREATE (3) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Asynch YesPRO: Avoids multiple resource/context zombies. Request context of previous request will anyway contain ri => easy to lookup Avoids sending multiple notifications CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May get duplicate creation of resources and request contexts => more zombies Need to rely on ‘garbage collection’ May end up with multiple notifications NoPRO: Avoids redundant forwarding of requests Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

8 Requested Operation: RETRIEVE, UPDATE (1) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) BlockingYesPRO: (none) CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: (none) NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

9 Requested Operation: RETRIEVE, UPDATE (2) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Synch YesPRO: Avoids multiple context zombies. Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May get duplicate creation of request contexts => zombies Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

10 Requested Operation: RETRIEVE, UPDATE (3) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Asynch YesPRO: Avoids multiple context zombies. Request context of previous request will anyway contain ri => easy to lookup Avoids sending multiple notifications CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May get duplicate creation of request contexts => zombies Need to rely on ‘garbage collection’ May end up with multiple notifications NoPRO: Avoids redundant forwarding of requests Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

11 Requested Operation: DELETE (1) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) BlockingYesPRO: Could repeat successful response => avoid confusion in Originator CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: If DELETE was already done earlier, an unsuccessful response may confuse Originator NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

12 Requested Operation: DELETE (2) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Synch YesPRO: Reuse old context => avoid confusion Avoids multiple context zombies. Req. context contains ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: If DELETE was done earlier, an unsuccessful response may confuse Originator May get duplicated request contexts Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

13 Requested Operation: DELETE (3) Request Type Receiver CSE = Hosting CSE Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Asynch YesPRO: Reuse old context => avoid confusion Avoids multiple context zombies. Req. context contains ri => easy to lookup Avoids sending multiple notifications CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: If DELETE was done earlier, an unsuccessful response may confuse Originator May get duplicated request contexts Need to rely on ‘garbage collection’ May end up with multiple notifications NoPRO: Avoids redundant forwarding of requests Request context of previous request will anyway contain ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

14 Requested Operation: NOTIFY (1) Request Type Receiver CSE = target or Registrar CSE of target Option 1 (keep track of request id) Option 2 (treat always as a new request) BlockingYesPRO: Avoid multiple notifications CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May end up with multiple notifications NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: Same request may be forwarded multiple times (could confuse CSE down the road)

15 Requested Operation: NOTIFY (2) Request Type Receiver CSE = target or Registrar CSE of target Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Synch YesPRO: Avoid multiple notifications Avoids multiple context zombies. Req. context contains ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May end up with multiple notifications May get duplicated request contexts Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: May get duplicated request contexts Same request may be forwarded multiple times (could confuse CSE down the road)

16 Requested Operation: NOTIFY (1) Request Type Receiver CSE = target or Registrar CSE of target Option 1 (keep track of request id) Option 2 (treat always as a new request) Non- Blocking Asynch YesPRO: Avoid multiple notifications to target/orig. Avoids multiple context zombies. Req. context contains ri => easy to lookup CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can process request without being aware of past requests CON: May end up with multiple notifications May get duplicated request contexts Need to rely on ‘garbage collection’ NoPRO: Avoids forwarding of requests that were already forwarded. CON: Need to keep track of ri What if some other parameters were different relative to previous request? PRO: Can forward request without being aware of past requests CON: May get duplicated request contexts Same request may be forwarded multiple times (could confuse CSE down the road)

17 Forwarding of requests from one CSE to another CSE due to duplication of requests that were intended to be just one −Buffering of what was meant to be just one request multiple times −Could create significantly more traffic on costly links Avoid replication of requests on subsequent hops when one hop is shaky (lost responses) When context of a request is anyway stored (non-blocking modes), avoid replication  Use option 1 when requests must be forwarded to another CSE & for non- blocking requests  In case of forwarding a request or for non-blocking, some ‘book keeping’ is anyway needed in most cases  Could avoid costly contexts, buffering and repeated transport over costly links  Use option 2 in other cases (blocking requests that need no forwarding)  CONs not that drastic, can probably be handled by garbage collection Proposal Relevant issues:

18 References to “Qualcomm” may mean Qualcomm Incorporated, or subsidiaries or business units within the Qualcomm corporate structure, as applicable. Qualcomm Incorporated includes Qualcomm’s licensing business, QTL, and the vast majority of its patent portfolio. Qualcomm Technologies, Inc., a wholly-owned subsidiary of Qualcomm Incorporated, operates, along with its subsidiaries, substantially all of Qualcomm’s engineering, research and development functions, and substantially all of its product and services businesses, including its semiconductor business and QCT. Qualcomm is a trademark of Qualcomm Incorporated, registered in the United States and other countries. Other products and brand names may be trademarks or registered trademarks of their respective owners. Thank you