quicwg
Missing PATH_ABANDON codes
Interface instability is a local choice, which maybe some implementations can detect. However, I would consider loss of the ability to communicate on a path to be a pretty strong reason for PATH_ABANDON, so maybe COMMUNICATION_FAILED.
Then there is the case where a path, such as a backup back, simply times out. TIMED_OUT.
And then there are a bunch of cases where the choice is not application-driven, but driven by other considerations, like POOR_PERFORMANCE.
What other things have implementation and deployment experience with the protocol revealed?
I think that we use "instability" to describe both the "communication failed" and "poor performance" conditions. That may or may not be the right word, we may want a new name, but I would suggest having just one code for now.
By timeout, do you mean the "idle timeout" discussed in 5.9. Idle Timeout and Keep-Alives? This kind of path closure is an application decision, as in "path as not been used for a long time, don't need it anymore." I would use the code APPLICATION_ABANDON
I agree with @huitema "poor performance" is what we cover by interface instability and "communication failed" seems to be just an extreme case of that. We do have a per-path timer in quic, so a time-out would rather occur on connection level. I'm not against adding further error code because we said we should be liberate with that but also not sure that's really needed. So maybe the only action would be to rename "instable interface"...?
More input from others would be welcome
This was discussed at IETF-123 but there was no further feedback on the need of additional error codes. I will leave this issue open for another week or two, at least until all current PRs are reviewed and approved. However, If there is no further feedback by then, the plan is to close without action.
@LPardue I think you said you might want to re-review that. Please do so soon if possible!
I tend to sgree with Christian. I like the idea of one error code but the name PATH_UNSTABLE_INTERFACE seems like too specific a name to me. PATH_UNSTABLE_OR_POOR seems good enough based on what's captured on this issue (with some minor prose change to the error code definition in 4.2.1 to cover an example of poor performance).
Error codes are cheap. If we find future deployments could benefit from a richer codespace, future work can define some more codes IMO
I personally have absolutely no opinion here but PR #600 implements the proposed renaming and adds a few words to the explanation. Hope that makes it easy for people to review/comment/approve!