Subject: [ippm] IOAM opaque state snapshot & pre-alloc mode - is there room for simplification?

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 25 Mar 2019 12:11:17 +0000

Taking one of the hall-way discussions from earlier today to the list:
The use of the IOAM pre-alloc trace option with the opaque state snapshot data-field can result in some inefficiencies in case the schemas for different opaque state snapshot within a  namespace have different lengths.

More explicitly:

* A deployment could have a set of n IOAM namespaces N(i) - with i={1,...n}

* Each namespace cloud have a set of m schemas S(i,k) with k = {1,..m}

* The opaque snapshot length of a schema S(i,k) would be Length(S(i,k))

In pre-allocated mode, the encap node would need to make sure that there is room for each potential opaque state snapshot to be added. I.e. It would need to add max(Length(S(i,k)) to each node-data(j) fields (with j=1{1,...,h} - h being the number of hops to be recorded.

This can cause quite a bit of overhead, i.e. unused space in the IOAM header, in case there is variance in the length across the schemas within a namespace. In addition, the encapsulating node needs to be aware of all S(i,k) and their length.

Question: Is this a real problem that we need to fix? One could argue that an operator should choose the opaque snapshot schemas wisely across different namespaces, so that the overhead issue does not surface. I.e. make sure that all schemas S(i,k) are of the same length for a specific i.

Thanks, Frank