Subject: Design Issue: Merge RST_STREAM and GOAWAY into a single ERROR frame type

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 13:04:12 -0700

As a simplification, I'd like to suggest that we merge the RST_STREAM
and GOAWAY frames into a single ERROR frame with the following
definition:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Error Code (32)                          |
+---------------------------------------------------------------+
|X|                  Last-Stream-ID (31)                        |
+-+-------------------------------------------------------------+

(note that this flips the field order from the GOAWAY frame)

A frame-specific GOAWAY flag bit (0x2) would be defined for the frame,
and the Last-Stream-ID field would only be included in the frame data
if this flag was set.

This does a couple of things for us:

1. It simplifies the error handling and reduces the number of core frame types.
2. It allows us to terminate a stream and terminate the session in a
single frame if necessary
3. It gives us a way of reporting non-terminal session errors
(currently RST_STREAM is forbidden to use stream id #0 and GOAWAY is
always terminal).

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 3 May 2013 13:34:02 -0700

IIRC, when this was brought up at the last F2F the rational for NOT doing
this was that frame types were cheaper than flags (256 frame types, 8
flags).

That being said I think we should consider combining them :)

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 13:53:27 -0700

Speaking candidly, if we find ourselves requiring more than 8 boolean
flags on an error frame we should all just quit and go home.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 18:01:57 -0300

This is a thread ripe for bikeshedding. Is there any major issue worth
solving?

If we're going to paint our bike sheds, my take is keep whatever color the
bike shed already has unless it really offends a number of people.

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 14:08:38 -0700

There is no bikeshedding going on at all. I made the motivation for
this clear up front: it's a simplification that addresses three
specific items. Note: there is an existing editorial note in the
existing draft that calls out the fact that we have no non-terminal
method of communicating non-stream related errors. If we can address
that item while also simplifying things a bit, then fantastic.

On Fri, May 3, 2013 at 2:01 PM, William Chan (陈智昌)
<[email-masked]> wrote:
>> >> 1. It simplifies the error handling and reduces the number of core
>> >> frame
>> >> types.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 18:12:29 -0300

Sorry, my implication is that I don't see any objective determination of
what's simpler here, just subjective views of which many people can have an
opinion. But if there's consensus on doing this, then by all means, let's
do it. I for one disagree and find the current way simpler :)

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 14:25:58 -0700

I also find the current way more obvious-- in wireshark and similar traces,
it is far easier to pick out the different opcode type (which is typically
rendered as the textual name of the opcode) as opposed to the numeric value
in some field.

-=R

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 14:34:53 -0700

Very well.  With that, however, we still have the outstanding ed note...
How do we want to report non-terminal session errors (e.g.  Session frame
too big) or do we treat all session errors as terminal using goaway?
On May 3, 2013 2:25 PM, "Roberto Peon" <[email-masked]> wrote:

> I also find the current way more obvious-- in wireshark and similar
> traces, it is far easier to pick out the different opcode type (which is
> typically rendered as the textual name of the opcode) as opposed to the
> numeric value in some field.
>
> -=R
>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 18:45:07 -0300

The lack of non-terminal session errors is reflective of the historical
SPDY developer bias towards hard failure modes, so we don't tolerate
implementation errors that may affect interoperability/correctness later
on. It's opinionated and definitely has its issues.

For "Session frame too big", my inclination would be to terminate the
session. Google Chrome is not tolerant of things it thinks servers should
not be doing :) I think it's been good for the ecosystem overall thus far.
Are there other errors you'd like to see be non-terminal?

On Fri, May 3, 2013 at 6:34 PM, James M Snell <[email-masked]> wrote:

>> On Fri, May 3, 2013 at 2:12 PM, William Chan (陈智昌) <[email-masked]
>> > wrote:
>>

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 14:55:58 -0700

I've got no strong opinion on it either way, we just need to make sure
it is communicated clearly. Holding the position that all session
errors are always terminal seems perfectly reasonable given that such
errors will almost always be the result of either an improperly
implemented, malfunctioning or malicious endpoint.

On Fri, May 3, 2013 at 2:45 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> The lack of non-terminal session errors is reflective of the historical SPDY
> developer bias towards hard failure modes, so we don't tolerate
> implementation errors that may affect interoperability/correctness later on.
> It's opinionated and definitely has its issues.
>
>>> On Fri, May 3, 2013 at 2:12 PM, William Chan (陈智昌)
>>>> opinion. But if there's consensus on doing this, then by all means, let's do
>>>> it. I for one disagree and find the current way simpler :)
>>>>
>>>>
>>>>> >> > IIRC, when this was brought up at the last F2F the rational for
>>>>> >> > NOT
>>>>> >> > doing

---

From: Patrick McManus <[email-masked]>
Date: Fri, 3 May 2013 19:33:05 -0400

I've found the current way to work well too.

otoh if there was a use case for rationale 3 (non-terminal session errors)
that seems like the one place where the new proposal is actually more
expressive. nothing comes to mind though.