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

[Lucas Pardue <[e-mail]>]

@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