Senders need to have some actions acknowledged before they take effect

[martinthomson]

There is a common problem throughout the draft whereby the document talks about state transitions triggered by sending a packet. This is necessary when the state causes resources to be committed, but when resources are freed it is invariably wrong.

Thus, we have two classes situations for a sender that need to be clearly distinguished:

1. Actions that reserve resources take effect as soon as the first packet is sent. This includes:

   • sending the first STREAM frame on a stream (which consumes a concurrent stream),
   • the first transmission of and STREAM data (which moves the flow control offset),
   • sending a packet that adds to the header table (which reduces the available space there),
   • etc...

2. Actions that release resources take effect when they are acknowledged. This includes:

   • sending a STREAM frame with the FIN flag set (which can release a stream),
   • sending a RST_STREAM frame (which can release a stream),
   • deleting a header table entry (which eventually frees space),
   • etc...

When describing these, we need to be careful to be very precise about these things. In particular, STREAM frames with a FIN flag can both consume resource and release them. The consumption happens immediately, but the release depends on acknowledgment.

[martinthomson]

Recent changes make this less necessary.