Hi Michel,
Thank you for the presentation - I’ve missed it and it clarifies some questions
I had on the discussions on the ML from the last days.
Actually, I’m not that concerned with the possible clashes, but mostly with the
possibility to use this mechanism for performance optimization. The aspect that
interests me the most is the re-mapping of the hashes, which combined with URL
hash compression can save 4 bytes from the URL and 4 bytes from the CBOR
representation in some cases (assuming only 1-23 resources are re-maped, 3
bytes saved if 23-255, which should rarely be used).
This is somehow similar to the third alternate approach, in which each YANG
module can specify the data node IDs.
To elaborate on this, if the YANG module can explicitly specify the hash value
of some of its items, I think that you could solve the hash clashes with a
deterministic algorithm working on the loaded modules. For example, if you have
modules A, B, and C.
1) Module A’s calculated IDs and module-defined data node IDs are put in the
table
2) For each additional module:
2.a) for each item, if there is a clash:
while there is a clashing hash value, item’s hash value ++
This way, for a fixed set of modules and node IDs you’ll have a collision-free
hash table. The benefit of this is, as it is deterministic, you can
pre-calculate the hash remappings offline / statically.
Another point is, in case someone wants to do something optimized, and remaps
hash value 1 in module A and B, module A’s item will remain with hash 1, while
module B’s item will become 2, both of which can be compressed efficiently in
the URL and the CBOR representation (and both of which will always be 1 and 2
if modules A and B are loaded in this order, with no preceding modules).
Unfortunately, my knowledge of YANG / NETCONF is still basic, so maybe I’m
missing something obvious which could render this impractical.
Best,
Alexander
> Le 3 juin 2015 à 18:05, Michel Veillette <[email protected]>
> a écrit :
>
> Hi Alexander
>
> At the last 6TiSCH bi-weekly call, 4 solutions have been presented to the
> hash clashes problem. Two based on a rehash table and two based on a new CoAP
> query parameter carrying the module name or registered module ID. This query
> parameter is used to select unambiguously the targeted data node(s) assuming
> that any hash collision within a module have been resolved at design time.
> You can find this presentation in attachment.
>
> Both of your proposals make sense to me but I still hope that the clash file
> can be avoided or be optional.
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> [email protected]
> www.trilliantinc.com
>
>
> -----Original Message-----
> From: core [mailto:[email protected]] On Behalf Of Alexander Pelov
> Sent: 3 juin 2015 11:01
> To: [email protected]; [email protected]
> Subject: [core] CoMI remote server clash file and YANG hash in URL
>
> Hello everyone,
>
> I would like to discuss with you to ideas/proposals in this mail, namely:
> 1) Caching the yang clash file on a remote server
> 2) Compressing the URL representation of YANG hashes
>
> 1) Caching the yang clash file on a remote server Even though hash collisions
> should happen rarely (if ever), there may be cases when it could be
> inevitable, and as such, it may be interesting to cache the clash_file
> somewhere on a remote server to avoid sending it over the constrained
> wireless interface. It could be used for other cases, where some frequently
> used resources are re-hashed for performance purposes. Maybe it would be
> interesting to allow the server to specify a remote location for the clash
> file? For static collisions or optimizations it could be that the YANG
> definition includes alternative hash values, which could be used in addition
> to the normal ones.
>
> 2) Compressing the URL representation of YANG hashes Another point (which is
> unrelated), is to elide the leading "A"s from the base64 representation of
> the hash in the URL (which corresponds to eliding the leading zeroes from the
> hash). As specified in section 5.4. a hash value of 0x0000007e will be
> encoded as AAAA_, but if the leading A’s are elided it will be simply _
>
> This could pose problems only if in the future the size of the hash values is
> increased from 30 bits to some other (higher) value.
>
> This, however, could be very useful when having to frequently access the same
> resource. In such case, the server/network operator may decide to re-hash the
> URI to a shorter version, e.g. the
> /sys:system-state/sys:clock/sys:current-datetime could be remapped from
> 0x15370408 and VNwQI to 0x1 and _
>
> Best,
> Alex
>
> PS.
> A typo (?), which may be already corrected, in the example of mod.uri on Page
> 26: the two responses have different scheme "mod.uri" and "moduri"
>
> _______________________________________________
> core mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/core
> <6TiSCH presentation on CoMI hash clashes r03.pptx>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
