Better compression of VarInts

[fluffy]

A one byte VarInt can only 64 values but most variable length encodings could express twice that many values.

The bandwidth of MoQ could be reduced, helping reduce global warming, by a better VarInt design for MoQ.

[kixelated]

QUIC varints use 2 bits in the first byte to express if the number is 1, 2, 4, or 8 bytes long.

Protobuf varints use 1 bit per byte to express if the number continues to the next byte. This is probably similar to what you're referring to.

QUIC is usually more efficient when encoding numbers greater than 2^14. Protobuf is only more efficient encoding numbers between 2^6 and 2^7.

Regardless, you already need a QUIC library for MoQ and it often comes with a VarInt encoder/decoder for free.

[LPardue]

So if I understand the problem statement, the issue is that reserving the 2 MSBs means that a value of 64-127 needs 2 bytes rather than 1 (and values 16384-32767 need 3 bytes rather than 2 etc).

Is there any idea how much this would affect MOQT traffic? If its isolated to a few message types, rather than defining another new primitive variable-length integer, we could consider structured variable-length messages. I.e. a VAR_FOO message would have two (or more) variants that support different length thresholds

8-bit version

VAR_FOO Message {
Type (i) = 0XF00,
Length (i),
Field that is commonly 0..255 (8)
}

16-bit version

VAR_FOO Message {
Type (i) = 0XF01,
Length (i),
Field that is commonly 256..65535 (16)
}

[fluffy]

If you only had one varint in the messages, yah, that would work. But does not really scale very well as you get more.

[LPardue]

Agree it doesn't scale well. I don't understand the concrete cases where 1 byte per field really matters that much. What sorts of MoQ things are significantly affected?

[ianswett]

Given we get to choose what types fit into a single byte, and we have a number of things like Object length that will typically need 2+ bytes, I'm not sure how many cases there are where the current approach is suboptimal?