GREASING fields?

[LPardue]

There's a few fields that are varints, supporting a huge 62-bit space of values. Yet only a handful of values are defined in this spec. That leaves plenty of space for future extension, but we've learned that you have to "use it or lose it". QUIC addresses this concern by GREASING a.k.a reserving a wide range of values that have no meaning and must be ignored - https://www.rfc-editor.org/rfc/rfc9000.html#section-22.3-7

We might want to consider similar here.

[GrumpyOldTroll]

Scanning thru the frames, I see:

• MC_STATE state
• MC_STATE reason
• Capabilities in MC_LIMITS and Tranport Parameter

I think the rest are all numerical values, did I miss any that you noticed?

For what to do with those, my initial thoughts are:

• I think we could make the MC_STATE state field a fixed size probably. It's hard to imagine what to do with an unknown state value besides tell the client to close the channel or maybe close the connection?
• The reason field in MC_STATE seems more analogous to the error code in CONNECTION_CLOSE, which I notice doesn't have any extra GREASE defined the way Transport Parameters does. (But I think nothing stops an implementation from sending undefined values by way of GREASE handling? Maybe that should be explicit?)
• I guess the bits in Transport Parameter's capabilities are sent without knowing what the server can support, so these have to be ignored by servers that don't understand them. I'm not sure how a client can grease these without potentially advertising support for something it doesn't actually support, do we have any analogies in QUIC for a case like this?

Actually, thinking thru the capabilities again is making me realize we maybe also need something besides MC_ANNOUNCE sent server-to-client to indicate server has multicast support, else a client can't send a new MC_LIMITS. Hmm, I think I will open a new issue for that. (edit: opened https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/95)

[LPardue]

I think it's useful to think about this throught the eye of extensibility. Is there anything we might add later that is safe to send without waiting for the peer to tell us it is safe first. The way to do this is to ignore unknown values. That's a design choice this specification should be clear about whether it supports it or not.

Given that there is a PR to change the capabilities to be a bit field, that is going to constrain the scope of problem that GREASING is intended to address. So I don't think any greasing is required there.

So then we are left with MC_STATE State or Reason codes. It turns out that, for some reason, QUIC transport doesn't GREASE error codes but HTTP/3 does. That might have been the reason for part of the confusion. Personally, given that the State field can potentially have non-trivial impact on the protocol at runtime, I think there is some benefit in asupporting future extensions via ignoring unknown state values and greasing that field. But maybe you disagree?

I'm not so worried about the Reason code, that's probably mostly used for logging or offline purposes.

[GrumpyOldTroll]

I guess if we assume other possible values for state are only in the style of DECLINED_JOIN, where they don't actually come with a change in the state, then we could ignore other values and grease them (like a REPORT_STATUS or something? A "NETWORK_SUPPRESSED" that you could send in addition to your separate JOINED state to indicate to servers that understand it that traffic is not actually expected because of a future multicast feature that reports success/failure of the IGMP membership propagation to the client, and a corresponding NETWORK_UNSUPPRESSED?).

By default I was thinking if we need future extensions to the state transition signals, they may or may not be no-ops to the current state, so ignoring them might not be right, and therefore support for the new improved state transitions would have to be negotiated in an updated transport parameters or something, and you're forbidden from sending unknown state transition signals to endpoints that haven't negotiated support for them, on pain of connection close/MC_EXTENSION_ERROR.

I guess I'm pretty agnostic here.

[GrumpyOldTroll]

However, this line of reasoning suggests to me that maybe we should have a list of capabilities (which can have unknown greasable capabilities) in the transport parameters instead of just a bitfield for ipv4/ipv6. Like maybe there's a difference between "I am currently capable of joining an IPv4 group" and "I understand how to interpret IPv4 addresses", and the 2nd could be a listed capability among potentially numerous capabilities, whereas the first remains a bit that can be updated by a later MC_LIMITS.