0xbaba is not random

[martinthomson]

QUIC registration rules strongly recommend that new codepoints be selected at random. Though this value might have been randomly selected, it stretches credulity somewhat to reach that conclusion.

Note that using a contiguous range is fine, but please start that range from a random point.

[mirjak]

The transport parameter uses a random value now. Should we also change the frame types to random values?

If we merger PR #227 we will change the transport parameter value anyway for the next revisions. So this might be a good point to also change the frames codepoints. or does it not really matter anymore given those non-random values are already implemented/used?

[marten-seemann]

It's my understanding that frame types don't need to use random values, since they're only valid if the use of the extension was negotiated.

[mirjak]

So can we close this issue now or is there anything else?

[kazuho]

@marten-seemann

It's my understanding that frame types don't need to use random values, since they're only valid if the use of the extension was negotiated.

I am not sure if there is such an exception for frame types or if it can be justified.

QUIC extensions are not expected to have overlapping frame types; otherwise, you might not be possible to use two extensions at once.

Therefore, we need the same rule of collision avoidance for frame types as transport parameters.

Besides, Multipath draft also defines an error code starting with 0xba...

[marten-seemann]

That is correct, however, the cases are a bit different.

You can never "take back" a transport parameter code point that has been used (even if it was just for an experiment), since there might still be nodes around using that transport parameter. That doesn't apply to frame types and error codes. You don't need to care about some experimental extension having used code point X, as you'll never risk running into a collision, unless you yourself support that experimental extension.

Of course, once it comes to the publication of the final RFC, code points need to be chosen to be unique, so extensions can be mixed and matched. I think this is guaranteed by having the frame type code space managed by IANA.

[kazuho]

@marten-seemann

You can never "take back" a transport parameter code point that has been used (even if it was just for an experiment), since there might still be nodes around using that transport parameter. That doesn't apply to frame types and error codes.

That's true for frames types, but I'm not sure if there is a consensus that use of the error codes are negotiated.

In fact, I think it is the contrary. We agreed that we should send a Multipath-specific error code prior to the completion of negotiation (see https://github.com/quicwg/multipath/issues/157#issuecomment-1489532046), and have adopted #252.

[marten-seemann]

That’s ok since error codes are governed by an IANA registry. However, that registry is only filled once the RFC is published, so that doesn’t really apply to draft versions.

[huitema]

@marten-seemann we could argue that point in multiple ways. In any case, the frame-id and error code must not change if the transport parameter ID does not change. We know that the next draft will propose a new parameter ID for multipath negotiation. It is thus a good time for picking non-controversial values, and avoid another change of the transport parameter later, maybe during WGLC.