Re: GOAWAY -> GTFO

On 27 January 2014 13:46, Amos Jeffries <squid3@treenet.co.nz> wrote:
>   "A General Termination of Future Operations (GTFO) frame (type=0x7)
> informs the remote peer to stop creating streams on this connection."

Sounds good.

> 2) The "future operations" appears to be redundant behind "terminate".
> Perhapse it should just be named GENERAL_TERMINATE.

Sounds like a name for a person not a description of a protocol feature.

> BUG #1:
>  I am noticing a discontinuity in the textual description of the frame:
>
> "the GTFO contains the stream identifier of the last stream which was
> processed on the sending endpoint in this connection. If the receiver of the
> GTFO 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" ...
>
> ... "An endpoint MUST treat a GTFO frame with a stream identifier other than
> 0x0 as a connection error ..."
>
> These appear to be mutually exclusive conditions on the use of stream-ID for
> that frame. If implementations follows the MUST condition there is nothing
> graceful about the closure or usefully done with the stream-ID.

Took me a while to get what you were at here.  There is a stream
identifier in the frame header.  That MUST be 0x0 for GTFO.  That is
separate from the Last-Stream-ID field in the body of the frame, which
can be any value.

> BUG #2:
>  From a state management perspective it is not clear what the recipient of
> these frames is being informed about. ie what should be done in the case
> where multiple streams are underway when GTFO is sent with a stream-ID.
>
>  * Should that be the last/highest completed stream-ID? if so, what happens
> to incomplete streams with numerically lower ID?

This is the highest stream identifier for which work could have been
done.  This includes streams that have completed successfully, streams
that have been partially handled, and even streams that /might/ have
been processed somehow (i.e., if uncertain, you should include it).

If there are lower numbered streams for which work has not been done,
then that's just too bad.

>  * Should it be the stream-ID before the oldest incomplete stream? if so,
> what happens to all the partially handled and complete streams with
> numerically higher IDs?

I don't think that's right.

>  * Should it be the stream-ID of the last frame processed?

Yes.

> if so, what is it
> actually telling the remote endpoint?

If I say GTFO(last-stream = X), then you know that the POST request
you put in stream X+2 was not processed and can be tried again.

> Going by the text interpretation I would expect the frame to have a
> stream-ID of 0x0 and a *payload* containing a *list* of the stream-IDs which
> are currently being processed (or relayed in the case of middleware). Such
> that the frame is marked as flow control and recipient can clearly identify
> fully which streams must be completed and which can be re-tried elsewhere.

Including a list is better in a sense, but it also requires more
granular tracking.  It doesn't seem to be that valuable on balance.
(I'll let others disagree with me, of course.)

Received on Monday, 27 January 2014 22:11:57 UTC