Subject: Re: [quicwg/base-drafts] Error codes (#211)

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Jun 2017 18:19:06 -0700

Moving discussion from #467 here.

@janaiyengar proposed retaining the following error codes.  Here are my reasons for removing them:

If the intent is to signal to the other side, then I can't see how HANDSHAKE_TIMEOUT or NETWORK_IDLE_TIMEOUT would be sent, so I removed it.

Similar to the timeouts, UNENCRYPTED_STREAM_DATA, INVALID_VERSION_NEGOTIATION_PACKET, and ADDRESS_VALIDATION_FAILURE can't be sent in anything.  Maybe if we managed to come to some conclusion about how to signal handshake errors (#608), then maybe this sort of error can be restored.

I have no idea how to signal PUBLIC_RESET_RECEIVED either.

TOO_MANY_RTOS seems to fall into the same category as the timeouts, but I can't tell because it isn't referenced anywhere.

All of the above seem to be best suited to passing across the interface between a QUIC stack and the application that uses it.

I removed CRYPTO_STREAM_CLOSED and PAYLOAD_MISSING on the basis that these were too specific, but I'm happy to retain them.  I'd prefer to open issues tracking their restoration so that we can add text on when they are generated (see below).

Finally, none of these error codes was referenced by text in the document.  If the document doesn't describe the conditions for generating the code, then they clearly weren't that important.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-310248684

---

From: ianswett <[email-masked]>
Date: Thu, 22 Jun 2017 07:34:00 -0700

Thanks for enumerating the removed error codes.

I suspect we'll want to reinstate some of those, but none of them seem pressing at the moment.

To clarify, the replacement for HANDSHAKE_TIMEOUT and NETWORK_IDLE_TIMEOUT is NO_ERROR?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-310398673

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Jun 2017 08:02:39 -0700

- CRYPTO_STREAM_CLOSED is duplicative of QUIC_CLOSED_CRITICAL_STREAM, and when you generate it is already covered in the transport doc.
- UNENCRYPTED_STREAM_DATA *might* be sent in something, depending when we receive it.  This actually seems like a worthwhile one to get out:  "You sent stream X != 0 in an unencrypted packet."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-310407369

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jun 2017 15:58:04 -0700

QUIC_CLOSED_CRITICAL_STREAM really only applies to stream 0, doesn't it?  I mean, if you take the view (as I do) that the transport shouldn't be closing streams at all (#485, @mnot keeps renaming my issues, which is really annoying), then the transport can't know about the special status of any other streams.

After the handshake, UNENCRYPTED_STREAM_DATA means packets that would be discarded.  If you do anything else, you open yourself up to unauthenticated packets closing your connection.  I don't know how to send this error code.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311509296

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Jun 2017 17:16:24 -0700

I will continue to annoy people who open needlessly specific issues; it'd be nice to stall issue #1000 until at least early next year. I'll also annoy those who make the issue title over-long, so that we can't fit all of the issue descriptions in a reasonable amount of space.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311521217

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Jun 2017 11:56:07 -0700

@martinthomson, the application can also use these error codes, or so I've been assuming.  So the HTTP layer will generate QUIC_CLOSED_CRITICAL_STREAM if the session control stream is closed.  You could split that up, but then every application will wind up defining its own version of "you broke it, dummy!".

True, after the handshake.  I envision this as being the following scenario:

  - Application has called the QUIC library to open a connection and dumped data into the first streams in hopes of 0-RTT (or 0.5 RTT on the server)
  - QUIC library accidentally leaks this pending data into handshake cleartext packets
  - Recipient generates this error on the affected streams or connection, depending on how aggressive it wants to be.

It's a fairly specific bug, sure.  It's effectively not possible after the handshake.  If you want to generalize it somehow, go for it.  But it *is* a valid form of peer misbehavior that you might want to signal to the other side.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311754415

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jun 2017 20:34:28 +0000 (UTC)

I'm increasingly of the opinion that applications shouldn't be using QUIC error codes, but you are right that doing that means some duplication of work across applications.  Based on what we currently have, the generic codes are either properly generic (NO_ERROR, INTERNAL_ERROR) or they are maybe only applicable to a subset of applications (CLOSED_CRITICAL_STREAM, CANCELLED).  I can't properly justify generalizing those codes at this point.  Management of error code spaces is not a feature that the transport needs to do, and meddling in that space is where we are currently headed.  I'd prefer to leave the RST_STREAM error code open for use by applications and leave the semantics of the code points entirely unspecified in QUIC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311780840

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jun 2017 13:41:53 -0700

> I'm increasingly of the opinion that applications shouldn't be using QUIC error codes

@martinthomson does that deserve to be a seperate (arch) issue?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311783266

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Jun 2017 21:22:18 +0000 (UTC)

Ah, so move in a direction where there aren’t just distinct ranges, but:

  *   CONNECTION_CLOSE specifies a QUIC error code
  *   RST_STREAM delivers an application-specified close reason with no transport-layer semantics

That would certainly allow us to dramatically shrink the error code space.

That implies, as you alluded to, that the transport should never abort an individual stream.  With the move to max-stream-ID, that seems possible, since using a stream ID beyond the limit could more reasonably be considered a fatal error.  It also implies that the application can’t abruptly close a connection, though, which I’m more conflicted about.

From: Martin Thomson [mailto:[email-masked]]
Sent: Wednesday, June 28, 2017 1:34 PM
To: quicwg/base-drafts <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Comment <[email-masked]>
Subject: Re: [quicwg/base-drafts] Error codes (#211)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F211%23issuecomment-311780840&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C38d86edd4b394d98185008d4be6513da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636342788729724436&sdata=Qef5oB4AY%2FGsOEUhkkJtY2l5DNVvPyqSi874uDslPd4%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEE2hQn3KBjhVSgvgZNmhOQLJ5Q8ZBpAks5sIrjTgaJpZM4LrwmI&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C38d86edd4b394d98185008d4be6513da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636342788729734444&sdata=HdFc0ULYUXExmLsrybytkNkGIsD7HDM1wcnkONu1JZU%3D&reserved=0>.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311795942

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jun 2017 21:27:04 +0000 (UTC)

I should have been clearer.  I think that we definitely *need* to have a way for the application to kill the connection.  That suggests that the error code in the transport could carry an application error code, in much the same way as we carry a frame number, I guess.  But that's details we can work out.  I want to know if there is enough interest in this for me to work up a proposal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311797050

---

From: Patrick McManus <[email-masked]>
Date: Wed, 28 Jun 2017 23:03:50 +0000 (UTC)

On Wed, Jun 28, 2017 at 2:22 PM, Mike Bishop <[email-masked]>
wrote:

> That implies, as you alluded to, that the transport should never abort an
> individual stream.

I find that a really powerful and attractive property. +1.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/211#issuecomment-311816080