Subject: [core] [CoMI] multiple operations in a single request

From: Thomas Watteyne <[email-masked]>
Date: Sat, 27 Jun 2015 00:32:01 +0200

In the 6TiSCH context, CoMI can be used to manage a TSCH schedule, which
involves adding/removing cells (atomic layer 2 resources).

Cells are represented in the 6top YANG model as a list called "CellList" (
https://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-03#section-4.1).
The way CoMI is written now (draft-vanderstok-core-comi-06), one CoMI
request is needed for each operation. That is, if I want to schedule 10
cells between nodes A and B, I will need 10 PUT requests to node A, and 10
to node B. If these are confirmable CoAP packets, that's a lot of packets.
These will be short requests, but will eat up an enormous amount of
bandwidth.

I'd like to be able to issue a single request to node A and a single
request to node B to carry out all of these operations, by aggregating
multiple "operations" in a single CoMI request (a single/small number of
CoAP packets).

What does CoMI offer me today to do this? Should we write the YANG model in
some particular way? What is envisioned in a future revision of CoMI to
answer this need.

Thanks,
Thomas

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Jun 2015 15:51:07 -0700

On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne <[email-masked]
> wrote:

> What does CoMI offer me today to do this? Should we write the YANG model
> in some particular way? What is envisioned in a future revision of CoMI to
> answer this need.
>
>
I think the YANG Patch media type could be used with CoMI.
This allows multiple edits on different target resources.

You could also do a plain PATCH on the datastore root, and provide
the subtrees you want to change.

> Thomas

Andy

>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 27 Jun 2015 10:49:46 +0200

Andy,

Thanks. https://tools.ietf.org/html/draft-vanderstok-core-comi-06 now says:

[p4] TODO: Introduce CoAP Patch options to allow modification to subsets of
resource.
[p24] TODO: Define where PATCH is needed.

I assume that you are introducing PATCH in -07. Can you quantify how
lightweight this will be, e.g. how many cells can I add/remove in a single
packet?

Thomas

On Sat, Jun 27, 2015 at 12:51 AM, Andy Bierman <[email-masked]> wrote:

>
>
> On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne <
> [email-masked]> wrote:
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 29 Jun 2015 09:01:37 +0200

Hi Thomas,

the latest (not published yet) version includes the use of the PATCH 
command.
There is a RFC on JSON patch, we could refer to that in the PATCH I-D.
Further link-format is sufficient, no?

The number of items in the payload depends on the the server.
If large strings need to be replaced, the size is quickly large.

I was thinking of just using JSON CBOR with payloads like:

{ hash1: value1,
hash2: value2}

and changing individual list items.

I don't know about YANG PATCH media type.

Peter

Thomas Watteyne schreef op 2015-06-27 10:49:
> [p4] TODO: Introduce CoAP Patch options to allow modification to
> subsets of resource.
> 
> lightweight this will be, e.g. how many cells can I add/remove in a
> single packet?
> 
> Thomas
> 
>> On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne
>> <[email-masked]> wrote:
>> 
>>> In the 6TiSCH context, CoMI can be used to manage a TSCH schedule,
>>> which involves adding/removing cells (atomic layer 2 resources).
>>> 
>>> Cells are represented in the 6top YANG model as a list called
>>> "CellList"
>>> 
>> 
> (https://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-03#section-4.1).
>>> The way CoMI is written now (draft-vanderstok-core-comi-06), one
>>> CoMI request is needed for each operation. That is, if I want to
>>> schedule 10 cells between nodes A and B, I will need 10 PUT
>>> requests to node A, and 10 to node B. If these are confirmable
>>> CoAP packets, that's a lot of packets. These will be short
>>> requests, but will eat up an enormous amount of bandwidth.
>>> 
>>> I'd like to be able to issue a single request to node A and a
>>> single request to node B to carry out all of these operations, by
>>> aggregating multiple "operations" in a single CoMI request (a
>>> single/small number of CoAP packets).
>>> 
>>> What does CoMI offer me today to do this? Should we write the YANG
>>> model in some particular way? What is envisioned in a future
>>> revision of CoMI to answer this need.
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 29 Jun 2015 09:34:53 +0200

Peter,
Thanks. I'm looking forward to "counting bytes" and see how compact a PATCH
operation is represented in CoMI.
Thomas

On Mon, Jun 29, 2015 at 9:01 AM, peter van der Stok <[email-masked]>
wrote:

>>>  (

---

From: Michel Veillette <[email-masked]>
Date: Mon, 29 Jun 2015 15:13:41 +0000

Hi Thomas

To facilitate the creation of this encoding, can you provide an example of what you want to archive using SQL style statement for example.

For example:

INSERT INTO CellList
   (CellID, SlotframeID, SlotOffset, ChannelOffset, LinkOption, LinkType, CellType, NodeAddress, TrackID)
VALUES
   (1, 0, 2, 5, 0x01, 0, 0, ?leafref);

Couple of comments:

·         CellID

The  CellID need to be unique since it’s the key within the CellList.

How the assignment of CellIDs  is expected to be done?

To be unique, should the server assign this value and return the value assigned to the client? (This might require the use of a RPC)

·         TrackID

Currently, the TrackID is implemented using the datatype leafref which is not supported by the current COMI draft

·         draft-vanderstok-core-patch-00

The current draft introducing patch don’t seem to allow multiple insertion within a list. If this is not the case, It will be nice to have an example added to this draft.

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com/>

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 29 juin 2015 03:35
To: [email-masked]
Cc: [email-masked]; Andy Bierman; core
Subject: Re: [6tisch] [core] [CoMI] multiple operations in a single request

Peter,
Thanks. I'm looking forward to "counting bytes" and see how compact a PATCH operation is represented in CoMI.
Thomas

On Mon, Jun 29, 2015 at 9:01 AM, peter van der Stok <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,

the latest (not published yet) version includes the use of the PATCH command.
There is a RFC on JSON patch, we could refer to that in the PATCH I-D.
Further link-format is sufficient, no?

{ hash1: value1,
hash2: value2}

Peter

Andy,

Thanks. https://tools.ietf.org/html/draft-vanderstok-core-comi-06 now
says:

Thomas

On Sat, Jun 27, 2015 at 12:51 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>>
wrote:
On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne
<[email-masked]<mailto:[email-masked]>> wrote:
In the 6TiSCH context, CoMI can be used to manage a TSCH schedule,
which involves adding/removing cells (atomic layer 2 resources).

Andy
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Jun 2015 17:51:27 +0200

Michel Veillette wrote:
> Hi Thomas
> 
>  
> 
> To facilitate the creation of this encoding, can you provide an example
> of what you want to archive using SQL style statement for example.
> 
>  
> 
> For example:
> 
>  
> 
> INSERT INTO CellList
> 
>    (CellID, SlotframeID, SlotOffset, ChannelOffset, LinkOption,
> LinkType, CellType, NodeAddress, TrackID)
> 
> VALUES
> 

An insert would generally be modeled as a POST in REST, returning the
server-chosen URI (which would include the CellID if that is indeed
server-chosen) in a set of Location Options.

> To be unique, should the server assign this value and return the value
> assigned to the client? (This might require the use of a RPC)
> 
> ·         TrackID
> 
> Currently, the TrackID is implemented using the datatype leafref which
> is not supported by the current COMI draft
> 
> The current draft introducing patch don’t seem to allow multiple
> insertion within a list. If this is not the case, It will be nice to
> have an example added to this draft.

Merge-Patch indeed does not address insertion into an array, only into a
hash.  But that is a matter of defining the PATCH format; we are not
limited to just RFC 6902 or 7386.

Grüße, Carsten