Subject: [quicwg/base-drafts] Out-of-order Flow Control (#370)

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Mar 2017 09:52:41 -0800

ILubashev's suggestion on #171 alludes to this; separating it out as a new issue.

Connection-level flow control is currently defined as a cumulative sum of all bytes _received_ on all streams.  However, if you receive STREAM frames out of order, you can know that more data is in flight, even if you haven't received it.  Currently, that data implicitly counts against the receiver's stream window (since it's a max offset), but not against the connection window.

This would allow the receiver of a DISINTEREST frame to silently stop retransmission if the STREAM w/ FIN had already been acknowledged (without generating a RST_STREAM) since the flow control states on both sides would be consistent.  However, it would also require more logic on STREAM receipt, since it's no longer just a running counter of the size of all received STREAM frames.

-- 
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/370

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Mar 2017 15:24:29 -0800

Don't we already have a problem if a sender sends a STREAM frame that overlaps with what has already been sent.  For example, you can't just count STREAM frame sizes if you receive octets 0-10 and 5-15 for the same stream.  That's possibly already a problem receivers have to handle because it's just a generalized form of receiving 0-10 twice.

-- 
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/370#issuecomment-285203361

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Mar 2017 15:40:17 -0800

That's true; I misremembered the resolution to #146.  Yes, the "sum of STREAM frames" has to come after duplicate detection -- it probably actually gets updated at the point where you add the new data into the buffer.

-- 
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/370#issuecomment-285206480

---

From: Marten Seemann <[email-masked]>
Date: Wed, 08 Mar 2017 18:37:41 -0800

I don't think it makes sense to only count the bytes received for connection-level flow control. It makes sense to check for flow control violations as early as possible, so if a peer receives a certain offset on a stream, it makes sense to account for *all* bytes up to that offset in connection level flow control, no matter if they have already been received or if they're still outstanding.
A more compelling reason is that the duplicate detection you mentioned above is not even possible, as we discussed in #146 when we considered the CONFLICTING_STREAM_DATA error (and this was one of the reasons we decided against this error).

Since the reply to a DISINTEREST frame is a RST_STREAM frame (which contains a final byte offset), I don't see any problems with connection-level flow control (I can't find ILubashev's suggestion in #171 that @MikeBishop is referring to though, so maybe I missed his point).

Just as a side note, this is how GQUIC and quic-go are doing connection-level flow control at the moment.

-- 
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/370#issuecomment-285237295

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 08 Mar 2017 20:57:31 -0800

The discussion was on the mailing list. I added a quick summary to #171.The most general form of the suggestion is:
1. Treating STREAM+FIN and STREAM_RST much more similarly (for the purposes of window accounting as well as other purposes)
2. Treating STREAM and STREAM+FIN/STREAM_RST similarly for the purposes of window accounting -- the topic of this issue.

-- 
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/370#issuecomment-285254849

---

From: janaiyengar <[email-masked]>
Date: Fri, 10 Mar 2017 12:16:36 -0800

Closed #370 via #378.

-- 
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/370#event-995492059