Consider lowering baggage limits

[dyladan]

considering trace instrumentation have to process and propagate these. much smaller limits are more reasonable, similar to the tracestate header. I'm not sure the rationale for those were fully inventoried, some looked a bit reverse engineered from hunches. I'll give a concrete example.

A number above 32 causes problems for those encoding pairwise as state changes cannot be tracked with a 64bit bitset (without tricks). Yes, we can use blocked bitsets and other techniques, but some care should be taken to not set limits hugely especially without relevant rationale to do so.

Originally posted by @codefromthecrypt in https://github.com/w3c/baggage/issues/22#issuecomment-622674052

I tend to agree with @codefromthecrypt here. The original limits were "inspired" by the limits of the set-cookie header which we borrowed our format from, but cookies are only meant to be sent between the user-agent and whatever service it calls. Baggage will need to be propagated by many more components in the system so its costs will be significantly higher for the same limits.

[yurishkuro]

I would like to understand the concern/motivation better.

The argument "baggage is propagated to many components" makes more sense in the context of the combined length of baggage, not the number of entries, and there are use cases when the baggage payload could be arbitrarily large (e.g. for passing detailed fault injection instructions, or the Pivot Tracing paper), so I don't agree that the total length needs to be lower, mainly because "lower" would not mean going from 4k to 2k, but rather to low 100s (as far as I understood from cloud vendors concerns), which would severely restrict the usability of baggage.

I don't quite follow the bitset example, can anyone explain it better? I.e. we are talking about passing an arbitrary set of key-value string pairs, where do the bitsets come into play?

[dyladan]

I don't quite follow the bitset example, can anyone explain it better? I.e. we are talking about passing an arbitrary set of key-value string pairs, where do the bitsets come into play?

I'm not 100% sure this is what @codefromthecrypt meant, but here is my best interpretation: When you receive a header, you create a 64 bit value. Each bit represents the "edit" state of one of the keys or values. If you edit a key or its value, you flip its bit to 1. If your bitset is == 0 when you make a new request, you can propagate the received buffer without decoding and reencoding it because you know no entries have changed.

IMO it's quite a specific processing restriction, but I included it since it was in the original comment that I created this issue from.

[dyladan]

I think the concern with setting limits too high is that platform vendors who need to propagate the headers could see it as overly burdensome. Same goes with any potential instrumentation vendors who wish to store and/or process the header. This cost is included for every request for these entites.

[dyladan]

We discussed this at the last couple working group meetings. @codefromthecrypt brings up a good point that setting the limits is arbitrary. What we were really trying to do is set a limit that wouldn't be overly burdensome for platform vendors, but would carry enough entries of enough length to be useful. I have heard from @SergeyKanzhelev that the original limits came from Set-Cookie, but when I looked at the Set-Cookie specification I found that the limits in that specification are actually lower limits instead of the upper limits that we have here.

In the meeting, I proposed that we actually set a lower limit that must be propagated at least in order for the header to have some minimum amount of utility, but to remove the upper bounds and leave it to the implementer to decide their limits based on their requirements. For example, one platform may have very strict overhead requirements that prevents them from propagating all but the minimum requirement, while another may wish to propagate a very large number of entries in order to unlock the most potential use cases for their customers.

I propose the following action items to resolve this issue:

1. Remove the current upper bound limits (8192 total bytes, 180 entries, 4096 bytes per entry)
2. Define the following minimum propagation requirements:
   1. At least 64 entries MUST be propagated
   2. At least 8192 bytes including delimiters MUST be propagated

This would provide the following benefits:

• A user can reliably assume 64 entries with length of 127 characters or less will be propagated
• A platform vendor with additional resources can enable much higher limits for their users as these are only minimum requirements, enabling use cases for their users which use more than 64 entries or which use longer entries.
• A platform vendor with very strict processing requirements can track changes with a 64-bit bit set and allocate a fixed-length buffer for serialization.