Subtlety between length and size.

[jonathan-dilorenzo]

Maybe this is clear in the lingua franca of the networking community, but I find the subtlety between the length of a field and the size of a field a bit confusing. Here are some examples of the usage in the specification:

In section 7.2.4 it says:

A header union is not considered a type with fixed length.

However, in section 8.19, it says:

Similar to headers, the size of a header union can be determined at compile-time.

And refers to section 9 where there's a table that includes (and similar for the minimum size):

header_union: max(foreach field(header_union) field.maxSizeInBits())

There is also this line in 8.10:

Additionally, the size of a variable-length bit-string can be determined at compile-time.

I believe this is basically treating the length as the runtime size of the type and using fixed length to denote that the runtime length is compile-time known? While it's using size to describe bounds on the runtime size? I.e. as a shorthand to describe that the minimum and maximum sizes are both respectively compile-time known?

Perhaps this can become clearer by changing 'size' to say 'minimum and maximum size' in the instances above? Is it worth further defining 'size' and 'length' in some way?

[grg]

From my point of view, "length" and "size" should be interchangeable.

For the examples you cited for header unions and variable-length headers, I would push for the text to be adjusted to refer to either "maximum size" or "minimum and maximum sizes".

For example, for 8.19:

- Similar to headers, the size of a header union can be determined at compile-time.
+ Similar to headers, the maximum size of a header union can be determined at compile-time.

(I might further clarify by adding "with variable-length fields" after "headers" since headers without variable-length fields are a static length.)

And for 8.10:

- Additionally, the size of a variable-length bit-string can be determined at compile-time.
+ Additionally, the maximum size of a variable-length bit-string can be determined at compile-time.

[vgurevich]

Please, note that when we talk about scalar types, we also use the term "width", like "fixed-width", "bit-width", etc, in many places in the spec. In the section 7.1.6.4 the spec says "dynamically-sized", when it refers to varbit and then it also talks about "fixed-sized" bit-strings, clearly using both "width" and "size" as synonyms.

So, yes, both "length", "width" and "size" can be used as synonyms and that's what people do.

I would think that these terms might have somewhat different connotation depending on the context. For example, we often think of a header that is something that is received/transmitted and thus is "long" (or "short") and that's why people often use the word "length" in that context. When we think of fields, we often think in terms of the corresponding table entries, containing these fields or operations on them and they tend to be "wide" or "narrow" (a typical expression would be something like "32-bit-wide"). Hence, we use the term "width." The term "size" is probably more generic in that sense, but all three terms are very useful.

If there are specific instances in the spec, where this creates a misunderstanding or confusion, let's point them out and discuss those.

[jnfoster]

After discussion at the May 13th 2024 LDWG, we agreed that @jonathan-dilorenzo would create a PR to improve the wording in the specification, including clarifying uses of "maximum size" as discussed above.