-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Give IMMEDIATE_ACK a 1 byte codepoint #216
Conversation
I don't think this PR achieves the intended effect. |
Thanks, I was having that thought, but assumed I must be mistaken. In that case, the existing value already was a 2 byte value and we don't need to change any text in the draft, correct? |
Not for this frame. |
I was just thinking that. Any suggested frame values for IMMEDIATE_ACK? |
Assuming that there is nothing attractive as a abbreviation, maybe it would be a good idea to pick the smallest unused value? From the pretty restricted 1-byte number space, we picked QUIC v1 frame numbers in order. Why not continue doing that? |
Actually at this point we probably should set them to TBD and then let them be picked and assigned by the experts when the RFC gets published. I think we can keep the old ones for experimentation (however, we never officially registered them which we should have done). I would assume the experts would then just pick the next one in order. |
We'll need implementation and interop before we can get to RFC. We need code points to do that. Asking for a provisional registration right now, for the value we intend to use later seems ok given the stage we are at. |
The values 0x00 to 0x3f require standards Action and can only be assigned as soon as the RFC is published. Therefore I basically suggest to keep using the current values for experimentation and only assign the final values on publication. |
Per https://datatracker.ietf.org/doc/html/rfc9000#section-22.1.4
My read is that we actually allow the provisional registration in the low code point space |
Ah, I only read this one: "Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal), inclusive, which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126]." But I guess the text you cite above says that provisional registration are always only "Specification required". That seem to circumvent the registration policy a bit. But I guess that's what it says. I think I both cases we should actually registered the code point(s) before submitting a new draft, especially if we want to ue the initial range. But again given there is already a number we are squatting on, I propose we keep that for experimentation and assign the final number on publication. That ensures that we don't do any additional changes anymore that would burn that code point. |
Sounds reasonable to me. Caveat: I am not a DE and have not yet tried this extension |
draft-ietf-quic-ack-frequency.md
Outdated
@@ -212,7 +212,7 @@ ACK_FREQUENCY frame, shown below: | |||
|
|||
~~~ | |||
ACK_FREQUENCY Frame { | |||
Type (i) = 0xaf, | |||
Type (i) = 0xaccf, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Type (i) = 0xaccf, | |
Type (i) = TBD, |
draft-ietf-quic-ack-frequency.md
Outdated
@@ -221,7 +221,7 @@ ACK_FREQUENCY Frame { | |||
~~~ | |||
|
|||
Following the common frame format described in {{Section 12.4 of | |||
QUIC-TRANSPORT}}, ACK_FREQUENCY frames have a type of 0xaf, and contain the | |||
QUIC-TRANSPORT}}, ACK_FREQUENCY frames have a type of 0xaccf, and contain the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
QUIC-TRANSPORT}}, ACK_FREQUENCY frames have a type of 0xaccf, and contain the | |
QUIC-TRANSPORT}}, ACK_FREQUENCY frames have a type of TBD1, and contain the |
draft-ietf-quic-ack-frequency.md
Outdated
@@ -576,7 +576,7 @@ registry under the "QUIC Protocol" heading. | |||
|
|||
Value | Frame Name | Specification | |||
-----------|---------------------|----------------- | |||
0xaf | ACK_FREQUENCY | {{ack-frequency-frame}} | |||
0xaccf | ACK_FREQUENCY | {{ack-frequency-frame}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0xaccf | ACK_FREQUENCY | {{ack-frequency-frame}} | |
TBD1 | ACK_FREQUENCY | {{ack-frequency-frame}} |
draft-ietf-quic-ack-frequency.md
Outdated
@@ -576,7 +576,7 @@ registry under the "QUIC Protocol" heading. | |||
|
|||
Value | Frame Name | Specification | |||
-----------|---------------------|----------------- | |||
0xaf | ACK_FREQUENCY | {{ack-frequency-frame}} | |||
0xaccf | ACK_FREQUENCY | {{ack-frequency-frame}} | |||
0xac | IMMEDIATE_ACK | {{immediate-ack-frame}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0xac | IMMEDIATE_ACK | {{immediate-ack-frame}} | |
TBD2 | IMMEDIATE_ACK | {{immediate-ack-frame}} |
@ianswett should we discuss this further? |
I'm happy to close this and then register permanent codepoints for the final draft. |
I've updated the PR to reflect the values I believe we should request from IANA. |
Codepoint in those ranges need standard action based on RFC9000. This those values can only be assigned when publication is approved. We should not put them in the draft now. |
I'm confused because the PR title doesn't match the content, so not 100% clear what the intent is. Regardless, we can in theory request early-assignment per https://datatracker.ietf.org/doc/html/rfc7120. Perhaps that's a bit too early since we want some more interop but let the chairs know if you want to pursue it. |
Title was out of date and has been updated. My only reason for preferring to ask for the codepoints now would be to avoid the complexity of 1 vs 2 byte IMMEDIATE_ACK frames for those who haven't yet shipped the 2 byte version, which includes me. Otherwise, I think it's fine to wait. That being said, given you have to negotiate the extension to have these frame types be valid, the only issue is if another extension tries using the same codepoint without registering it and one wants to use both extensions at once. But that does seem to be the point of provisional registrations with IANA, so maybe we should register it now? |
The two options are we either a) ask for provisional registration now (which we should have done for the all other codepoints anyway) and wait for draft submission until assigned. Or b) we submit now with the old values and start last call right away in order to get this done quickly. |
I've put in a provisional registration request to IANA for 0x1f and 0xaf frame types. I'm also requesting provisional registration for the new transport parameter 0xff04de1b. Should we anyway also registered the old values (transport parameter 0xff04de1a and frame type 0xac) or are we sure these have never been deployed? Also I want to note that while it is true that frames are only valid if an extension is negotiated, by creating this registry we basically have we only have one number space for all extensions and I don't think we intended to have multiple entries for the same value in the registry...? It is true that it is easier to re-use provisional assignment because you have to negotiate a transport parameter, however, not sure if that was really the intention with this process. |
Note provisional allocation and request permanent allocation to IANA when document is approved for publication.
I updated this PR to request permanent allocation on approval for publication. I assume we want a new, shorter transport parameter for the final RFC, right? |
I think we'll want a new, shorter TP for the RFC, yes. |
Fixes #181 by making IMMEDIATE_ACK 0x1f
ACK_FREQUENCY already has a 2 byte codepoint.
Also changes the transport parameter value, because this is not backwards compatible.