Subject: [quicwg/base-drafts] hq: Does ignored data/frames cause flow control updates? (#1580)

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Jul 2018 07:13:23 -0700

This is triggered by the addition of greasing unidirectional stream types. Is ignoring stream data at the application level classed as consuming it from the transport, hence triggering a window flow control update (in the form of MAX_STREAM_DATA).

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jul 2018 08:44:59 -0700

Closed #1580.

-- 
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/1580#event-1740491326

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jul 2018 08:44:59 -0700

This isn't a problem.  Flow control in QUIC (the transport) is robust in the face of RST_STREAM and STOP_SENDING.

-- 
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/1580#issuecomment-405978115

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Jul 2018 08:51:28 -0700

Wait, the problem is not wanting to close the stream but the opposite i.e. keeping greased streams open for transferring data as a background noise signal. This will get blocked unless the receiver can update flow control related to data that is intended to be ignored.

-- 
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/1580#issuecomment-405980576

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Jul 2018 10:01:06 -0700

It's not the transport protocols concern what an app does or does not do with the data.
A std. QUIC api would deliver data in order, but can arrange for data to be delivered out of order to the app and even ignored. It is the primarily the app the knows how much buffer capacity can absorbed but it may flow to the transport in different ways - for example the app can say this range is not important and this range has been received - leaving capacity in the transports receive buffer that it can then use to update MAX.
If this becomes a problem, the app needs to negotiate this with the local app/transport interface but it hasn't got anything to do with the wire protocol.

-- 
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/1580#issuecomment-406003376

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Jul 2018 10:30:54 -0700

@mikkelfj I'm not sure what level of API you are talking. For HTTP/QUIC the spec in [3.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#stream-mapping). currently says:

> A QUIC stream provides reliable in-order delivery of bytes, but makes no guarantees about order of delivery with regard to bytes on other streams. On the wire, data is framed into QUIC STREAM frames, but this framing is invisible to the HTTP framing layer. A QUIC receiver buffers and orders received STREAM frames, exposing the data contained within as a reliable byte stream to the application.

So I guess I'm asking for clarification or guidance on whether an application-level receiver is expected to influence transport flow control when ignoring certain kinds of STREAM data that are not HTTP/QUIC frames. e.g. a statement to the effect of "ignored bytes still count towards STREAM flow control credit and should be a handled in as defined elsewhere". 

Why is this important? The HTTP/QUIC spec has just added greasing in https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.3.3.1

> Stream types of the format 0x1f * N are reserved to exercise the requirement that unknown types be ignored. These streams have no semantic meaning, and can be sent when application-layer padding is desired. They MAY also be sent on connections where no request data is currently being transferred.

earlier in the text we have:

> Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING frame with an error code of HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an error of any kind.

In this case the MAY is never enacted.

-- 
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/1580#issuecomment-406012069

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Jul 2018 17:49:31 +0000 (UTC)

My comments are purely in relation to transport. I can't say if there is unclear language in the HQ spec.

Even if HQ is a primary use case for QUIC, the transport cannot be concerned with how an application uses data. So it HQ (the app in this case) layer needs to notify the transport when to advance MAX or it must have another semi-automatic way to signal this as I suggested earlier. So the answer to the question must be a yes - the app must help transport advance flow control as long is it expects to receive more data - on that stream in particular, and on streams in general due to the global flow control credits. Also if a given range is ignored.

When a stream is terminated using RST there is an exact stream offset included. Data up to that offset counts against the global flow control while the max for the specific stream no longer matter because it is retired and pending data will not wait for more credits on that stream.

Due to race conditions data might be sent after the RST offset and there could be multiple RST's. However, if there are multiple RST's they must agree, or it is a protocol violation.

I assume that data sent after the RST offset will be rolled back from global credits counting, but I'm not entirely sure about this. Perhaps this should be clarified?

-- 
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/1580#issuecomment-406017758

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Jul 2018 10:58:24 -0700

That last comment on RST is incorrect - RST is in the forward direction. It is STOP_SENDING that is the concern here. This is only a guidance so anything received until the sender says that it is over counts toward flow credits.

-- 
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/1580#issuecomment-406020498

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jul 2018 11:10:32 -0700

You can't change QUIC semantics at the HTTP layer, so any data will require flow control credits.  Of course, if the recipient isn't consuming that data, they won't send credit.  In other words, for streams that are used for greasing, the recipient isn't likely to consume data, or send flow control credit and that's OK.  The point of the greasing is to ensure that the stream can be sent without causing problems, not that it is useful for any particular purpose (and here you seem to be suggesting that it might be useful for padding).

If you want a padding stream, make a new type with that purpose.

-- 
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/1580#issuecomment-406024098

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Jul 2018 11:18:37 -0700

I'm not suggest, this is what the current text implies (from Section 9). 

> HTTP/QUIC can rely on QUIC’s own PADDING frames or employ the reserved frame and stream types discussed in Section 4.2.1 and Section 3.3.1.

As Martin suggests, it might be better to define an explicit padding stream extension for anyone that actually wants that behaviour (which I think could be useful).

-- 
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/1580#issuecomment-406026704

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 Jul 2018 09:51:18 -0700

@MikeBishop I'm interested in your view because you wrote the (IMO) offending text. I don't want to flog a dead horse if others think this is a non-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/1580#issuecomment-406660084

---

From: Mike Bishop <[email-masked]>
Date: Fri, 20 Jul 2018 10:00:37 -0700

Yes, if the application closes a stream for read, the transport can discard that data, and should treat it as equivalent (for flow control purposes) to the entire payload having been consumed.

-- 
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/1580#issuecomment-406662758

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 Jul 2018 10:27:59 -0700

So perhaps my understanding of ignoring is misaligned. I'd write a client that doesn't close a read stream (for unidirectional reserved streams) and just carry on telling the transport layer I processed the data when in fact I did nothing with it. From transport layer perspective I suppose I handled 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/1580#issuecomment-406670552