Subject: Reserving error codes for "local" errors

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Nov 2020 22:19:00 -0800

I wonder whether we could reserve three error codes to signal
"immediate" termination conditions of a connection:

* termination by idle timeout,

* termination after losing network connectivity,

* termination after multiple PTO expired.

These are errors that need to be signaled by transport to application.
Clearly, it could be done with an implementation-defined API, but it
would be nice if the codes were in the same number space as the
transport errors like "CONNECTION_REFUSED" or "PROTOCOL_VIOLATION". That
number space is effectively unlimited. I suppose I could just squat on
some values, but there is always the risk of colliding with some later
definition.

I understand that I could use the extension mechanism for the error code
space, write a draft and somehow manage to get it approved by an expert,
published as an RFC, and have the numbers registered by IANA. But that
feels like a lot of work, so I was wondering whether we could just add
three codes in section 22.4 of the transport draft.

Any opinion in this group?

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Mon, 9 Nov 2020 01:52:07 -0500

I'd certainly use standard error codes for the first and third if we had
them, since we use those today in our implementation and they've been very
useful for application debugging.

The second one seems useful, but a bit fuzzier to me, because loss of
connectivity can show up in a variety of different ways.  Are you thinking
of cases when the local OS knows there's no connectivity, opposed to
blackholing, which is more ambiguous?

Ian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 09 Nov 2020 19:30:18 +1100

> These are errors that need to be signaled by transport to application.

Our implementation has no need for this capability[1], and as the codes don't traverse the network, it's not clear that any protocol needs these either.  As these are probably stored in 64-bit values, from which we have only taken a quarter of the possible values, why not use the other 13835058055282164000 values available that you can be assured QUIC will never take?

[1] Rust enums are weird from the perspective of a C programmer.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 9 Nov 2020 19:35:17 +0000

We at once point had an error code region defined for local use, IIRC.  We
removed them.  I think Martin's suggestion provides a good workaround for
anyone who wants to combine implementation and protocol error codes.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Martin Thomson
Sent: Monday, November 9, 2020 3:30 AM
To: [email-masked]
Subject: Re: Reserving error codes for "local" errors

> These are errors that need to be signaled by transport to application.

Our implementation has no need for this capability[1], and as the codes
don't traverse the network, it's not clear that any protocol needs these
either.  As these are probably stored in 64-bit values, from which we have
only taken a quarter of the possible values, why not use the other
13835058055282164000 values available that you can be assured QUIC will
never take?

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 9 Nov 2020 16:10:05 -0800

We discussed this way back, I think in Paris. We decided then, IIRC, to
leave local error codes out of the document, and only include the ones that
are communicated over the wire.

There will be many more local error codes; are these three any more special
than, say "Received a Stateless Reset"? I agree with Martin on
implementation, You can simply number internal error codes starting from
0xff00, for instance, if you want an easy way to demarcate, and to not
worry about collision in the future (this is what our implementation does).