Re: GOAWAY -> GTFO

On 2014-01-28 11:11, Martin Thomson wrote:
> On 27 January 2014 13:46, Amos Jeffries 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.

Ah, overlooked that. Perhapse some wording

"The last stream identifier (Last-Stream-ID) in the GTFO frame contains 
..."

"The last stream identifier (Last-Stream-ID) in the GTFO frame payload 
contains ..."


> 
>> 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.

Thank you.

> 
>> 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.)

Both ends already have that tracking in place. The costs I here would be 
the extra bytes on the GTFO frame and the cycles used to generate that 
list in the sender for which streams it still wants to receive. The 
cycles to process it in recipient would be the same ones for clearing up 
that state anyway.

This may have benefits such as allowing the recipient to change its 
priority algorithm to send frames for shorter outstanding streams, thus 
closing as many streams as possible completely before anything else goes 
wrong. Or in handling as errors any outstanding streams the sender does 
not list instead of the recipient wasting bandwidth sending their 
frames. A list of only one entry (as currently used) meaning the 
connection close is to follow and everything outstanding is borked.

Amos

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