Hi Andy See [MV] Inline
Both solutions rely equally on the YANG module writer to solve any hash clashes within 1 module. The advantage of a module-id is that if this is done, no re-hash is needed at all. How is a Data Node ID encoded? Not sure how that works. [MV] The Data Node ID is a integer, I changed the name to open the door to the support of both managed and unmanaged ID. For module implementing unmanaged IDs, this integer contains the current 30 bits mm3 hash. For module implementing managed IDs, this integer contains an assigned ID. This feature can be used to reduce significantly the payload size (~50%) Another possible application is the mapping of Zigbee ZCL clusters to CoMI modules while keeping the same attribute (Data Node) ID. This is not a mandatory feature but there is not much efforts required to support this since both approaches use integers, we just need to add some description texts. The cost of the module-id is really in the message encoding. [MV] If we still support access with the Data Node ID only with the possibility to receive a clash error, this overhead is optional. For example: REQ: GET example.com/mg/VNwQI // May return a clash error REQ: GET example.com/mg/?select=ietf-system // Never return a clash error Or this alternate approach if we want to support the retrieval of multiple data nodes: REQ: GET example.com/mg? select=VNwQI,folNh // May return a clash error REQ: GET example.com/mg/?select=ietf-system(VNwQI,folNh) // Never return a clash error What if the protocol allowed the client to discover a set of module-name to local-module-number mappings that can be used as the module-id in messages? [MV] Cool idea, this is a nice alternative to a registry. Can we use /.well-known/core to implement this feature? If we do so, I think that both the module name and a module ID should be supported. This way, this extra handshake use to retrieve these module IDs can be skipped when this optimization is not required by the client (Short interactions or larger frame supported) The client has to store the module name anyway (that is 'Module ID' since modules are not assigned numbers). The extra storage is 1 number (16 bits?) per module, per server. Maybe 32 bytes per server. Would that be too much? [MV] Seem reasonable I would like the module-id approach if the encoding was a number instead of a string. [MV] As mentioned above, I thing we should support both. Andy [cid:[email protected]] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 [email protected]<mailto:[email protected]> www.trilliantinc.com<http://www.trilliantinc.com/> From: Andy Bierman [mailto:[email protected]] Sent: 21 mai 2015 20:03 To: Michel Veillette Cc: [email protected]; [email protected]; Core Subject: Re: [core] CoMI rehashing On Thu, May 21, 2015 at 9:32 AM, Michel Veillette <[email protected]<mailto:[email protected]>> wrote: Hi Peter We seem effectively to be on the same intersection (YANG, CBOR, YANG hash) but still on the opposite side of the street. The core difference seem to be the expected data struture implemented by the CoMI server. All your solutions all based on flat hash table represented below. [cid:[email protected]] All my solutions are all based on a hash table per module context represented below. [cid:[email protected]] This alternate data structure enable a different set of solutions such as: • Access using either the “Data Node ID” alone (if unique) or “Module ID” + “Data Node ID” NOTE: When a clash exist, an alternate “Data Node ID” can be returned by the CoMI server for subsequent requests using the “Data Node ID” alone. • Access to all data nodes of a module NOTE: The CoMI server know which data nodes are part of which module and can return those if a query parameter (select) ask to do so. • Ability to support a mix managed/unmanaged model where some modules may use manage Data Node IDs and others may use YANG hashes NOTE: If we also want to support managed and unmanaged “Module ID”, we can use a special character like # to differentiate between them. Module ID prefixed by # can be unmanaged module name, Module ID not prefixed by # can be IANA registered module ID. The advantage will be to minimize the overhead associated to some popular modules. Within a module, all data nodes need to be either manage or unmanaged • Most importantly, this data structure enable different methods which avoid the need to implement a rehash list, its retrieval and storage I’m open to compromise on multiple aspects of the solutions (support of not of managed Module ID, managed Data node ID, specific message format and query parameters). However, I will have hard time to compromise on this fundamental difference. About “OK, but the message overhead argument remains.” • On the CoMI server side, I don’t consider that adding a dozen of “Module ID” and splitting the hash table in pieces represent an unacceptable overhead, especially if we remove the rehash list. • On the protocol side, if we allow access using the “Data Node ID” alone and if we return an alternate “Data Node ID” in case of a clash for subsequent requests seem to me more efficient than retrieving a rehash list. Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 [email protected]<mailto:[email protected]> www.trilliantinc.com<http://www.trilliantinc.com> -----Original Message----- From: peter van der Stok [mailto:[email protected]<mailto:[email protected]>] Sent: 21 mai 2015 05:27 To: Michel Veillette Cc: [email protected]<mailto:[email protected]>; Andy Bierman; [email protected]<mailto:[email protected]>; Core Subject: RE: [core] CoMI rehashing Hi Michel, We are not far apart, it seems to me. There is one thing left in my view: - Server returns new hash value to client, or - Client reads new hash value from a supporting file (called "clash-file") The supporting file is introduced to remove storage requirements from server, such as: data node name, name extension, module name, hashes. And it makes rehash handling for large clients (storing the data node names) and for small clients (storing module names only) similar. The "clash-file" is still needed when the server returns the new hash value to store data node name and name extension. By returning the new hash value the server is burdened with the module name storage. few comments below in <pvds2> comment </pvds2> Peter
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
