Subject: [quicwg/base-drafts] 0b05b9: Rework draining period into two (or three) states

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Oct 2017 22:20:31 -0700

Branch: refs/heads/draining-closing
  Home:   https://github.com/quicwg/base-drafts
  Commit: 0b05b99661c01e881f5e317ce22f4369224b0589
      https://github.com/quicwg/base-drafts/commit/0b05b99661c01e881f5e317ce22f4369224b0589
  Author: Martin Thomson <[email-masked]>
  Date:   2017-10-25 (Wed, 25 Oct 2017)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  -----------
  Rework draining period into two (or three) states

As @ekr points out, there was definitely more than one closing state.  I've
modified this to the following three:

1. draining - when you know that the other side is closing, this is just to
   absorb stray packets

2. closing - when you have initiated the close and you need to re-send the
   close in addition to absorbing stray packets (this could be longer than the
   3RTO period if we like, but I've opted for keeping a shared timer)

3. timed out - when you timed out, and you are willing to revive the connection
   if new packets arrive; this one being optional

In the process I realized that we needed greater clarity about how to respond
to a closing frame (thanks to @huitema for the prompting).  I allow the
recipient to generate one closing frame, but no more than that.  They enter the
draining period thereafter and can't send any more packets.  Having two peers
in the closing state could result in a constant back-and-forth.

Editorial: I added the term "closing frame" to cover CONNECTION_CLOSE and
APPLICATION_CLOSE collectively, which were getting cumbersome.

Closes #871.