Subject: [QUIC] Unnecessary QUIC error codes

From: Dmitri Tikhonov <[email-masked]>
Date: Sun, 6 Nov 2016 19:53:23 +0000

Fellow QUICsters:

I read through the new QUIC draft (Octber 31, 2016) and I think I see several error codes that do not belong in the protocol.  Some of them have too much "chrome," others seem to have bled through from the code onto the draft, so to speak.

Category I: Chromisms

QUIC_MAYBE_CORRUPTED_MEMORY

Looking at the code, what is considered potential memory corruption by QuicConnection::MaybeConsiderAsMemoryCorruption() is subjective.  An implementation should not try to guess how its peer corrupts memory.

QUIC_PACKET_TOO_LARGE

This is a Chromism because kMaxPacketSize is defined in Chromium code, but not in the document.

QUIC_STREAM_SEQUENCER_INVALID_STATE

This is a Chromism (what's a Stream Sequencer?).  It also falls into Category II (see below).

QUIC_TOO_MANY_SESSIONS_ON_SERVER

Chromism: what is a session?

Category II: Doctor It Hurts When I Do This

A guy goes to see a doctor.  "Doc, it hurts when I do this!"  "Don't do it, then."

QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA

QUIC_FAILED_TO_SERIALIZE_PACKET

Category III: Telepathic Packet Delivery

QUIC_PACKET_WRITE_ERROR

If we can't write to socket, how will the peer learn of this error code?

QUIC_ENCRYPTION_FAILURE

If we can't encrypt a packet, how does the CONNECTION_CLOSE frame get sent out?

Thanks,

Kelly.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 7 Nov 2016 12:01:30 -0800

Hi Kelly,

Thanks for your read of the draft! Yes, indeed this listing is of "all
possible" QUIC errors since the draft is currently a documentation of
current QUIC.

The point of listing them all was for the wg, after adoption, to figure out
what to do with them. Some of these error codes are sent over the wire, and
others are not -- the draft currently incorrectly states that these are all
CONNECTION_CLOSE frame error codes. These are certainly connection close
error codes, but not all of them are communicated to the peer.

We may drop the local error codes, since they have no business being in the
protocol (The ones in your "Telepathic Packet Delivery" category.) That
said, we may choose to keep some of them as suggestions for reasons that an
implementation MAY close a connection.

The Chromisms that you note should be fixed --
QUIC_STREAM_SEQUENCER_INVALID_STATE: means that the receiver's stream
reassembly engine is in some funky state
QUIC_TOO_MANY_SESSIONS_ON_SERVER: sessions are the same as connections

I'll put this email on the list of things to fix post-adoption. Thanks
again!
- jana

On Sun, Nov 6, 2016 at 11:53 AM, Dmitri Tikhonov <[email-masked]>
wrote:

> Fellow QUICsters:
>
>
> I read through the new QUIC draft (Octber 31, 2016) and I think I see
> several error codes that do not belong in the protocol.  Some of them have
> too much "chrome," others seem to have bled through from the code onto the
> draft, so to speak.
>
>
> *Category I: Chromisms*
>
> Looking at the code, what is considered potential memory corruption by
> QuicConnection::MaybeConsiderAsMemoryCorruption() is subjective.  An
> implementation should not try to guess how its peer corrupts memory.
>
>
> QUIC_PACKET_TOO_LARGE
>
>
> *Category II: Doctor It Hurts When I Do This*
>
> *A guy goes to see a doctor.  "Doc, it hurts when I do this!"  "Don't do
> it, then."*
>
> *Category III: Telepathic Packet Delivery*
>
>
> QUIC_PACKET_WRITE_ERROR
>
>