Please use a draft frame codepoint

[DavidSchinazi]

The draft currently uses frame type 0x20. That number requires Standards Action and can't be used in drafts as it risks conflicting with another draft. Please use a multi-byte encoding for now, we can switch to a lower number for both the transport parameter and the frame after WGLC.

[marten-seemann]

Are you aware of any collisions, @DavidSchinazi? The only draft I'm aware of that defines new frames is ACK frequency, which uses 0x1f and 0xaf.

While I agree that transport parameters should use random values, I don't think this applies to frames, since use of the frame is gated by the negotiation of the extension.

[DavidSchinazi]

Are you aware of any collisions, @DavidSchinazi? The only draft I'm aware of that defines new frames is ACK frequency, which uses 0x1f and 0xaf.

Yes, we have a collision inside of Google QUICHE for an earlier Google-internal version of the DATAGRAM draft.

While I agree that transport parameters should use random values, I don't think this applies to frames, since use of the frame is gated by the negotiation of the extension.

The recommendation to use random values applies to frames as well, because they can also conflict when both extensions are negotiated.

[LPardue]

I don't 100% agree. This is an adopted work item on a standards track that is ready for a WGLC. We can provisionally register the frame codepoint under these terms IMO (for why, see https://datatracker.ietf.org/doc/html/rfc9000#section-22.1.1). Issues of interop within the extension itself are handled by the TP as Marten explains. Regardless of the value, we should request IANA to provisionally register a value for RESET_STREAM_AT as we approach RFC.

I appreciate that there appears to be a conflict with a private extension but I'm not sure that's the fault of this draft. If the conflict exists now, are there plans for Google to address this on a reasonably short timescale? Absent such plans, it would appear it doesn't matter if we change to a random value today, the value 0x20 is problematic. I don't think changing the value today with an expectation we can change back for RFC should be subject to the timelines of a single vendor.

To make progress, we instead might want to consider provisional registration of a different low-numbered value for RESET_STREAM_AT today, to provide a runway to RFC. Ack frequency already has done this. If so, Google might seek to provisionally register 0x20 in order to avoid further accidental conflicts while they manage their deprecation process - the registration guidance recommends codepoints can be reclaimed after 12 months, which seems like a reasonable timescale.

[DavidSchinazi]

Requesting early allocation is perfectly reasonable per IANA's rules. But until then the draft is squatting. From an engineering perspective, Google can make 0x20 work. But we've had a process for QUIC codepoints for a reason - because implementing this draft could lead to protocol changes that would lead to another conflict (which can be mitigated by changing the transport parameter value but not always). Here's how I see the QUIC codepoint process to be:

1. new draft starts with random multi-byte number
2. interop testing and ideally production testing
3. WGLC
4. early allocation of a new one-byte codepoint as provisional.
5. Publication - that makes the code point permanent

The early allocation process in (4) ensures that there cannot be a collision because the IESG is involved.

In this case, we need to replace (1) with "replace incorrect first choice of codepoint with random multi-byte number" and then follow the rest of the process accordingly.

For what it's worth, this draft did the right thing for the transport parameter - so it will need to make a wire-breaking change to switch to the final transport parameter codepoint. Doing the same for the frame avoids the risk of a conflict and does not have any downside.

[LPardue]

I'm ready to start WGLC. Given where we're at I don't see there being much value in changing the frame code point for 2-4 weeks to then change it back.

[DavidSchinazi]

Is this deployed to production anywhere? Is there a cost to following our process and using the right codepoint for drafts?

[LPardue]

The process makes sense for other documents in early stages for sure. We should take this as a learning exercise and write it up on quicwg.org so future drafts do the right thing no matter what WG they are using. The chairs can hold the pen.

What I'm suggesting here is that we be pragmatic. The value has been active for 6+ months and there are implementations. Changing that now will require changing the frame type and the transport parameter and explaining, somehow, that we expect to change them again once WGLC finishes. That sounds like busy work to me, and worse if it distracts the WG. What technical upside is there to do so in this specific case?

[kazuho]

Could we rev a new draft that uses a different 1-byte frame type (e.g., 0x21) before starting WGLC and call it a day?

As we become near to publishing the final RFC, it becomes harder to change code points, and I totally agree with @LPardue that we do not want to switch twice.

But maybe we can switch just once at this moment, as we do not have any production code (or dependency from other drafts) yet that uses reliable resets.

[LPardue]

That sounds a reasonable compromise to me (ensuring we note the registration is proviaion in iana instructions). I would use WGLC as the barometer for consensus to then formally initiate the early allocation process.

[DavidSchinazi]

Switching to a different one-byte value works for me. The draft should say something like Status: Provisional (but will become Permanent once this document is approved). Please pick it randomly (though I'll let the authors define randomness). Then you can immediately ask the designated experts for provisional registration, no need for the early allocation process.

[vasilvv]

I believe the one we have conflict for is a pair of 0x20/0x21. For what it's worth, I could probably work this around, but it would take less time if I didn't have to (= we'd get to interop for the draft sooner, which is something I was hoping for here).