Subject: [quicwg/base-drafts] Stream closed state and acknowledgments (#743)

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Aug 2017 01:35:09 +0000 (UTC)

We've prevaricated on this one, and I don't think that we have consensus on the outcome.

Does a stream become closed when all data is sent the first time, or when that data is acknowledged?  The same question applies to RST_STREAM: is the stream closed when RST_STREAM is sent, or when it is acknowledged?

With the move to maximum stream identifiers, this question matters less than it did previously, but I think that it still deserves an answer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Aug 2017 21:55:35 +0000 (UTC)

Thinking modularly, I'd argue that it should happen when the frames are submitted for transmission; the stream state machine shouldn't be dependent on ACKs and retransmissions.  The receiver is necessarily going to lag a little bit due to those things, but the situation of there being a lag is not remedied by making the lagging party be the sender instead.  This also mirrors flow control, where the window is consumed as soon as the frames are submitted, even if they haven't been sent yet.

As you note, the reason we considered switching the lag was to make the sender more conservative about which streams are in which state to avoid accidentally violating max_concurrent_streams.  That's no longer an issue, since the receiver is the one controlling that now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743#issuecomment-324162922

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Aug 2017 17:29:38 -0700

It depends on the model you assume.  That assumes a handoff between the stream and some transmit/retransmit machinery.

The other model, one that I prefer, is one where the transmission machinery pulls from available streams.  It uses priority to determine what to send, preferring data that has already been sent.  In that case, data on streams could remain attributed to the stream until it is acknowledged.  The advantage here is potentially better prioritization and the cost is a potential increase in the number of bytes that are outstanding without acknowledgment.

Neither model is more modular than the other, the line just appears in a different place.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743#issuecomment-324187648

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 31 Aug 2017 23:05:16 +0000 (UTC)

If the question is specifically about when the stream is closed, doesn't
the state diagram make it clear that it's when the FIN is sent, not when
the FIN is ACK'd?

                            +--------+
                            |        |
                            |  idle  |
                            |        |
                            +--------+
                                 |
                        send/recv STREAM/RST
                             recv MSD/SB
                                 |
                                 v
                 recv FIN/  +--------+    send FIN/
                 recv RST   |        |    send RST
                  ,---------|  open  |-----------.
                 /          |        |            \
                v           +--------+             v
         +----------+                          +----------+
         |   half   |                          |   half   |
         |  closed  |                          |  closed  |
         | (remote) |                          |  (local) |
         +----------+                          +----------+
             |                                        |
             |   send FIN/  +--------+    recv FIN/   |
              \  send RST   |        |    recv RST   /
               `----------->| closed |<-------------'
                            |        |
                            +--------+

On Tue, Aug 22, 2017 at 5:29 PM, Martin Thomson <[email-masked]>
wrote:

> It depends on the model you assume. That assumes a handoff between the
> stream and some transmit/retransmit machinery.
>
> The other model, one that I prefer, is one where the transmission
> machinery pulls from available streams. It uses priority to determine what
> to send, preferring data that has already been sent. In that case, data on
> streams could remain attributed to the stream until it is acknowledged. The
> advantage here is potentially better prioritization and the cost is a
> potential increase in the number of bytes that are outstanding without
> acknowledgment.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/743#issuecomment-324187648>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ysIBUxSjFgyl_B1XpJvt7HABvFQlks5sa3JygaJpZM4O-AeX>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743#issuecomment-326443532

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Aug 2017 21:03:53 -0700

Yes, the document - in its current form - is quite clear on this.  The issue exists to determine whether this is *desirable* in addition to being documented, because we have in the past had some confusion on this point.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743#issuecomment-326481757

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 31 Aug 2017 21:16:49 -0700

Ah, I see. Good point. Not surprisingly, I prefer the "closed when sent"
interpretation. This allows a relatively clean separation between the
"stream" layer (open stream accounting, flow control, etc) and the "packet
layer" (packet framing, retransmissions, etc). I agree with Mike that since
we no longer have max_streams it doesn't seem like there's a compelling
reason to require the FIN be ACK'd in order to consider the stream closed.

On Thu, Aug 31, 2017 at 9:03 PM, Martin Thomson <[email-masked]>
wrote:

> Yes, the document - in its current form - is quite clear on this. The
> issue exists to determine whether this is *desirable* in addition to
> being documented, because we have in the past had some confusion on this
> point.
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/743#issuecomment-326483057