Subject: [quicwg/base-drafts] RST_STREAM can (still) cause flow control problems (#1878)

From: martinduke <[email-masked]>
Date: Wed, 17 Oct 2018 15:44:42 -0700

In a bidirectional stream, if I receive a RST_STREAM, how am I to know how much of the data I have *sent* is counting towards connection flow control?

For example, say I send 10 STREAM frames on stream 0, of 1000 B each, receive a RST_STREAM for stream 0 with offset 0, and then acks for packets 1:4 and 6:10. It is clear that I should deduct zero of the credit I am granting to the peer, but it is not clear how much connection credit the peer has deducted for this stream.

One way to solve this is to have a receive offset field in RST_STREAM. When I receive one of these, I can flush the send queue and recover any credit I had taken from myself. In this case, if the RST_STREAM had  a max receive offset of 1000, I'd add 9000 back to my connection credit.

Inveterate optimizers might want this field to only exist for bidi streams. I don't particularly care.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 Oct 2018 22:57:41 +0000 (UTC)

Isn't this covered here:
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.1

More generally though - I'm not sure exactly which frames count toward flow control - e.g. what about a lost padding only packet that is never retransmitted?

-- 
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/1878#issuecomment-430817809

---

From: martinduke <[email-masked]>
Date: Wed, 17 Oct 2018 16:03:58 -0700

No, the offset field in RST_STREAM addresses only one direction -- the correct final offset from RST_STREAM sender to RST_STREAM receiver. I spent some time trying to figure out if the spec expected me to send RST_STREAM in response to RST_STREAM, and I decided that wasn't the case even though the uni stream state machines sort of imply it.

The final offset from RST_STREAM receiver to RST_STREAM sender is never explicitly communicated, as far as I can tell.

> More generally though - I'm not sure exactly which frames count toward flow control - e.g. what about a lost padding only packet that is never retransmitted?

It's STREAM contents only that count. Other frames, like padding, aren't buffered by the receiver.

-- 
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/1878#issuecomment-430819244

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 17 Oct 2018 16:04:56 -0700

@mikkelfj Flow controls applies to data sent on streams in the form of STREAM frames. It does not apply to packets or other frame types. So a lost padding frame would have no bearing on flow control.

-- 
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/1878#issuecomment-430819398

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 Oct 2018 16:26:42 -0700

@RyanAtGoogle thanks - I did implement it once, but it was more than a year ago.
@martinduke I see. But (and this is weak memory) I think that each direction is handled separately. Resetting one direction does not terminate the other - the stream just transitions into what was formerly known as a half-open state. Otherwise you are right, it would be a problem, and if not, perhaps the text need some clarification.

-- 
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/1878#issuecomment-430823674

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 Oct 2018 16:32:21 -0700

https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.9.2.4
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.1.1
"A bidirectional stream is composed of a send stream and a receive stream. Implementations may represent states of the bidirectional stream as composites of send and receive stream states."
"RST_STREAM terminates one direction of a stream abruptly."

-- 
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/1878#issuecomment-430824668

---

From: Mike Bishop <[email-masked]>
Date: Wed, 17 Oct 2018 16:53:43 -0700

@mikkelfj is correct -- each direction is independent.  If you receive a RST_STREAM, the data flowing toward you has ceased abruptly.  This does not inherently mean that you cannot respond.  If you choose not to respond, send a RST_STREAM yourself, which then contains the flow control information you're discussing.

Is there text we should clarify for this?

-- 
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/1878#issuecomment-430828668

---

From: martinduke <[email-masked]>
Date: Thu, 18 Oct 2018 16:47:38 -0700

If RST_STREAM begets a return RST_STREAM, that's news to me. If everyone is happy with this state of affairs, I'll file a PR to make that a bit clearer in the spec. (I explicitly looked for this in the spec before filing, and couldn't find it). I suppose it's implied by the state machines and so forth, but this is different from HTTP/2 and probably could be more explicti.

-- 
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/1878#issuecomment-431200308

---

From: ianswett <[email-masked]>
Date: Fri, 19 Oct 2018 01:28:54 +0000 (UTC)

Yup, that's how it sort of needs to work, since both sides need to communicate an offset, and the two ways are via a FIN'd stream or a RST_STREAM frame.

A PR to clarify that is always helpful.

-- 
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/1878#issuecomment-431215726

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Oct 2018 01:50:55 +0000 (UTC)

Having just re-read the section on this, I don't agree that there is a problem.  The text is very clear on this in Section 4.1, which specifically addresses the interaction of stream cancellation and flow control:

> RST_STREAM terminates one direction of a stream abruptly. Whether any action or response can or should be taken on the data already received is an application-specific issue, but it will often be the case that upon receipt of a RST_STREAM an endpoint will choose to stop sending data in its own direction. If the sender of a RST_STREAM wishes to explicitly state that no future data will be processed, that endpoint MAY send a STOP_SENDING frame at the same time.
-- https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#handling-of-stream-cancellation

To answer the question:

> In a bidirectional stream, if I receive a RST_STREAM, how am I to know how much of the data I have sent is counting towards connection flow control?

You have to assume ALL of it.

-- 
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/1878#issuecomment-431219254

---

From: MikkelFJ <[email-masked]>
Date: Thu, 18 Oct 2018 21:38:00 -0700

Also note that RST does not require peer RST, the peer can alternatively continue sending data and/or FIN

________________________________
From: Martin Thomson <[email-masked]>
Sent: Friday, October 19, 2018 3:50:49 AM
To: quicwg/base-drafts
Cc: MikkelFJ; Mention
Subject: Re: [quicwg/base-drafts] RST_STREAM can (still) cause flow control problems (#1878)

To answer the question:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/1878#issuecomment-431219254>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AALzN11Tfnl2ij7Aa83LEAh3nYaIS3Upks5umS_5gaJpZM4Xqhjn>.

-- 
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/1878#issuecomment-431242500

---

From: martinduke <[email-masked]>
Date: Fri, 19 Oct 2018 17:29:20 +0000 (UTC)

Renaming this issue to reflect the real problem, though I guess I'm the only one that was confused. I'll file a small PR to scratch my itch

-- 
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/1878#issuecomment-431438132

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Oct 2018 16:02:00 -0700

Merged #1893 manually.

-- 
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/1878#issuecomment-431711801

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Oct 2018 16:02:03 -0700

Closed #1878.

-- 
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/1878#event-1916877049

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Oct 2018 16:16:47 -0700

GitHub is acting out here.  Fix merged manually.

-- 
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/1878#issuecomment-431712899