Re: GOAWAY and proxies (#458)

On 22 April 2014 09:37, Daniel Sommermann <dcsommer@fb.com> wrote:
> So the first GOAWAY acknowledges the last stream seen +
> 2*MAX_CONCURRENT_STREAMS and then 1 RTT later the server sends a second
> GOAWAY with the actual last seen stream? This seems like it could work in
> practice, but RTT isn't always stable so it seems like this mechanism could
> be flaky.

I wasn't suggesting that it be exactly 1RTT.  Maybe worst-case RTT
plus a fair amount of slack.  That's probably still far smaller than
the timer you are running today (i.e., you could use that timer
happily.)

> The 2xGOAWAY approach would result in a smaller diff to the spec though. We
> would just need to add some text about expecting 2 GOAWAYs where the first
> GOAWAY may acknowledge a stream id greater than any initiated stream.

Yes.  I want to ensure that we explain what is going on.  That
definitely means text.  I'll put together a proposal.

> However, from an implementation point of view I think a new frame is more
> straight forward and less error prone. With the new frame, you don't have to
> measure RTT or do arithmetic. DRAINING is a completely empty frame. In both
> solutions 2 frames are sent, but with a new frame type, the purpose of the
> two frames is more clear.

I'm not sure that the problem is any different.  You still have to
ensure that you wait long enough after sending DRAINING before you
send the GOAWAY (the above math is exactly the same).  The difference
is that for a client, two GOAWAY frames are treated exactly the same,
i.e., clients don't need two code paths.

Received on Tuesday, 22 April 2014 17:02:30 UTC