Alternate status values in PATH_STATUS

[qdeconinck]

The draft currently defines two possible values in the PATH_STATUS frame. However, it does not defines if other values are usable, neither does a receiver should behave with alternate values.

Probably the right behaviour would be to state that alternate values might be application-dependent, and otherwise the status value might be ignored.

[LPardue]

Discussed in IETF 116, strong sense in the room to use two different frame types instead

[mirjak]

I started a PR for this issue. See #242. However this needs more discussion as there are multiple options which all my have some problems.

Option 1) The current PR creates two new frames. The idea of this change was to make it easy to add potential new status value in future by simply adding a new frame. However, having separate frames means the frames may arrive in different orders. In PATH_STATUS we had a frame sequence number; but to guarantee order among frames, this would mean all "path-status" frames would need to share a seq number space. I don't think that would be a complicated solution to implement but it does not feel like a clean design to have these dependencies among frames.

Option 2) We could have a one PATH_STANDBY frame which always contains a full list of all CID seq numbers that should have this state and as such any update would always replace the old state. That means we could signal multiple updates in one frame, which can beneficial e.g. if you change CIDs on all paths, and further we would not need the PATH_AVAILABLE frame at all. However, this only works with two path states and also not if we in future want to define another path status frame. However, are we sure we need different exclusive states? E.g. If you would later define a path priority, this information can be orthogonal to the standby information rather than replacing it.

Option 3) Only allow sending of path status information on the same path that the updates applies to and use the packet number for ordering. However, this means you cannot "assign" status information to a CID before the CID is used which at least theoretically would be possible with the other solutions. However, maybe it's sufficient to ensure that if a new CID is used the respective path status frame is sent in the first packet with this new CID. Not sure how complicated that would be for some implementations. Also is using packet number for order a good choice? Might also be complicated for some implementations...?

Or Option 4, I guess, is to keep the current PATH_STATUS frame (and find a different way to make it extensible or make any future extensive a full replacement).

[kazuho]

@mirjak Thank you for working on this issue.

Based on the previous consensus, I think my preference goes to option 1. I do not think that there is additional complexity with sharing the sequence number with multiple frames that update path status. In my view, we are merely merging the Path Status field that exists today into the frame type.

As to option 2, people who want to update states of all paths at once can do that with option 1, by sending multiple frames covering all paths at once in a single packet. Therefore, option 1 is a superset of option 2.

Re option 3, yeah it would be complicated for some QUIC stacks. IIUC, there are two types of stacks; when a packet is lost, some QUIC stacks regenerate frames. Other QUIC stacks remember what has been sent in the encoded form and simply retransmit them. For the latter, it is hard to exclude frames carrying old information upon retransmission.

[huitema]

@kazuho what happen if the client sends PATH_STATUS_STANDBY and then PATH_STATUS_AVAILABLE, but for some reason the packets arrive out of order at the server?

[kazuho]

@huitema IIUC, what @mirjak is stating in option 1 is that the two frame types share a single sequence number space. The receiver can use the sequence number to determine which of the two frames carry the latest information.

[huitema]

Yes, but that's a bit ugly. Do we have any other example of different frame types relying on a single sequence number? Could we consider using something else, maybe a packet sequence number or a time since beginning of connection?

[marten-seemann]

Maybe it helps to frame it as PATH_STATUS_STANDBY and PATH_STATUS_AVAILABLE being two variants of the same frame, that only differ by one bit in the frame type (e.g. like MAX_STREAMS frame in RFC 9000)?

[kazuho]

@huitema We already have precedent. NEW_CONNECTION_ID and RETIRE_CONNECTION_ID share the same sequence number space. If you receive RETIRE_CONNECTION_ID(seq=x) then NEW_CONNECTION_ID(seq=x, ...), latter is ignored.

That said, I agree with @marten-seemann that we can ease the friction by editorial means. Like having a section for PATH_STATUS_* frames, talk about the sequence number, then describe the each variant of the frame that serves a specific purpose (e.g., available, standby).

[huitema]

Or we can keep the design that we have currently, a single "PATH_STATUS" frame with a set of enumerated values. The main drive for the proposal to move to separate types is to reuse the extension mechanism for creating new frames, but I am a bit skeptical. If I wanted to create a new path status such as "only available if the temperature reaches 45 degrees Celsius", I could do exactly the same thing as for creating a frame: pick a numeric value for the status, and describe in a draft the transport option used to negotiate use of that new numeric value. Or values.

[huitema]

@marten-seemann if we envisage having more than 2 values, then we cannot guarantee that all the newly created values will have consecutive frame numbers. Quite the opposite. The new frame numbers will be defined as extensions, which in theory use frame numbers picked at random.

[marten-seemann]

@huitema No strong opinion. If you want to allow extensions to define new statuses, would that mean we have to create a new IANA registry for status points? There'd need to be some mechanism to avoid collision between code points defined by different extensions.

Another option would be to reserve a slice of (consecutive) frame code points. For example, you could define that all 0xbaba06nn (nn being the last byte) are PATH_STATUS frames, where this document would define the values 0 and 1 for nn. This would limit us to 256 path statuses before we'd have to give up on the property that these frames are all consecutive (new statuses could still be defined outside of that range).

[LPardue]

Discussed in IETF 117, still a strong preference for using two frames