The stream ID in GOAWAY

[mnot]

"An endpoint that encounters a session error MUST first send a GOAWAY frame with the stream identifier of the last stream that it successfully received from its peer."

What does that mean? Is it the stream ID of the last frame received from its peer, regardless of who initiated the stream? Is it the last successfully initiated stream by the peer?

We also use "peer" a fair amount without defining it...

[mnot]

In GOAWAY:

        There is an inherent race condition between an endpoint starting new streams and the
        remote sending a GOAWAY message.  To deal with this case, the GOAWAY contains the stream
        identifier of the last stream which was processed on the sending endpoint in this
        session.  If the receiver of the GOAWAY used streams that are newer than the indicated
        stream identifier, they were not processed by the sender and the receiver may treat the
        streams as though they had never been created at all (hence the receiver may want to
        re-create the streams later on a new session).

I think this really needs to be (in both places) "the last stream successfully initiated by the peer."

"Processed" is misleading.

[martinthomson]

Yes, agreed on all counts. The definition of "processed" and even "received" needs to be a lot crisper. And peer is used enough times to also have a crisp definition.

The intent is to use GOAWAY to indicate the last stream that has been received AND acted upon in its entirety.

The behaviour of GOAWAY under error conditions clearly needs to be different because the connection close follows immediately, whereas a GOAWAY under a graceful shutdown can be sent well ahead of the connection being closed, allowing streams to complete safely.

[jpinner]

A few comments:

1. The intent has not been to indicate the the stream has been acting upon in its entirety -- the stream may still be open and data being transferred. Which of course leads to:

2. Connection close only follows immediately for session errors, but this does not mean that the behavior of GOAWAY must be different. It is an indication that a stream has at least been acknowledge so may not necessarily be resent automatically unless idempotence is guaranteed.

The current use of the frame (at least on the server side) has been to indicate the highest numbered stream ID that will not be refused.

So for example if a client has initiated streams 1, 3, 5, and 7, with streams 1 and 5 being half-closed on the client side and 3 and 7 being open, the server on shutting down the connection would send a GOAWAY frame with stream ID 7, indicating that it will continue to accept frames for streams 3 and 7 but will refuse to accept streams 9 and higher.

In the session error case, the meaning of the frame does not have to change, even if connection close follows immediately. It indicates to the client that stream 9 may be resent automatically but streams 3 and 7 may not.

[martinthomson]

Take a look at the edits that I made in the above commit and let me know if that helps. This captures, I hope, what @jpinner was trying to explain.