Support 64 bit Var Int values

[fluffy]

To facilitate mapping object ID to existing 64 bit is not possible.

[LPardue]

What shape of solution is acceptable here? QUIC varints are limited to 62 bits (64 minus 2 reserved for the length indicator). Is the suggestion to have 125 bits (128 minus 3) and require implementations to handle this as 128 bits?

Or maybe just "extend" the varint by add a new MSB field to messages that require full range of 64 bits e.g

MSB (2)
Unused (6)
BigVal (i)

Then a parser, which already represents varints as u64, can just combine the two fields to create the actual value?

[fluffy]

That's a bit ugly but I think it meets the requirements.

[kixelated]

...are you using a u64 timestamp as an object ID or something? And those high two bits are mandatory to support or is this a theoretical overflow in a billion years sort of thing?

But I do agree that encoder overflows above 2^62 are annoying to deal with. However, a VarInt that can represent larger values is equally annoying because of decoder overflows. Only a VarInt encoding that represents exactly 64 bits would be an improvement IMO but the math doesn't quite work out.

But Cullen it continues to feel like you're abusing Object ID with such huge numbers and gaps. Can you put this u64 (timestamp?) inside of the payload instead of the MoqTransport header?

[afrind]

We discussed in the meeting today and agreed this needs motivating use cases