Subject: Need any QUIC stream errors?

From: Martin Duke <[email-masked]>
Date: Thu, 7 Feb 2019 09:09:16 -0800

I noticed that Stream Errors have gone away as a transport-layer concept
recently. Most protocol violations (e.g., flow control) are now
connection-level failures, and the error code in RESET_STREAM exists for
application purposes.

However, how should I communicate some sort of QUIC internal error that
aborts the stream? For example, if there's a memory corruption or malloc
failure in the stream send queue, a RESET_STREAM would be sufficient.
Should I send with no error code, or take down the whole connection? Or do
we need to reserve one stream error codepoint for this case?

---

From: Mike Bishop <[email-masked]>
Date: Thu, 7 Feb 2019 18:14:07 +0000

So far, we’ve taken the position that streams contain application data, so the reason for terminating a stream is exclusively in the application’s domain.  If something is wrong with the transport layer, it (potentially) impacts the entire connection.  I’m content with the idea that an E_OUTOFMEMORY can blow up a connection.

From: QUIC <[email-masked]> On Behalf Of Martin Duke
Sent: Thursday, February 7, 2019 9:09 AM
To: IETF QUIC WG <[email-masked]>
Subject: Need any QUIC stream errors?

I noticed that Stream Errors have gone away as a transport-layer concept recently. Most protocol violations (e.g., flow control) are now connection-level failures, and the error code in RESET_STREAM exists for application purposes.

However, how should I communicate some sort of QUIC internal error that aborts the stream? For example, if there's a memory corruption or malloc failure in the stream send queue, a RESET_STREAM would be sufficient. Should I send with no error code, or take down the whole connection? Or do we need to reserve one stream error codepoint for this case?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Feb 2019 10:42:09 -0800

Yes, it is a great simplification to only have application assigned stream
errors. There was a long discussion (is 0 special) that lead to a change in
how RESET_STREAM / STOP_SENDING handles the error flow in order to keep it
strictly application level.

If anything goes wrong with a stream, it can go to the application, e.g.
out of flow credits for too long, which can then decide. The stream as such
is not harmed even if it has outlived its useful lifespan.

On 7 February 2019 at 19.14.25, Mike Bishop ([email-masked]) wrote:

So far, we’ve taken the position that streams contain application data, so
the reason for terminating a stream is exclusively in the application’s
domain.  If something is wrong with the transport layer, it (potentially)
impacts the entire connection.  I’m content with the idea that an
E_OUTOFMEMORY can blow up a connection.

*From:* QUIC <[email-masked]> *On Behalf Of * Martin Duke
*Sent:* Thursday, February 7, 2019 9:09 AM
*To:* IETF QUIC WG <[email-masked]>
*Subject:* Need any QUIC stream errors?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Feb 2019 10:07:37 +1100

An application might need to be aware of stream cancellation.  For instance, if a request stream is reset in h3, the compressor has to signal this or the compression state can lose synchronization.