[quicwg/base-drafts] QPACK decoder stream buffer grows without bounds (#2999)

Tatsuhiro Tsujikawa <notifications@github.com> Fri, 30 August 2019 15:55 UTC

Date: Fri, 30 Aug 2019 08:55:23 -0700
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6UYNQ52YITZOX5UPF3OZ4WXEVBNHHB2D4G5I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2999@github.com>
Subject: [quicwg/base-drafts] QPACK decoder stream buffer grows without bounds (#2999)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d6946ebe4e2d_6d1d3f91338cd96813570"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/HXlFUGPyPmZL5wuks9jO4MYmmCw>

If I understand correctly, the decoder stream buffer which endpoint has to keep grows indefinitely if encoder-side app does not return back flow control credit.
The number of Header Acknowledgement instruction is bounded by the number of max blocked streams which decoder can specify.
On the other hand, the number of Stream Cancellation is not bounded.  So if encoder-side app keeps resetting stream without sending MAX_STREAM_DATA, decoder-side has to keep all closed stream in decoder stream.  I'm not sure this has been discussed already.



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

Re: [quicwg/base-drafts] QPACK decoder stream buf… Mike Bishop
[quicwg/base-drafts] QPACK decoder stream buffer … Tatsuhiro Tsujikawa
Re: [quicwg/base-drafts] QPACK decoder stream buf… Mike Bishop
Re: [quicwg/base-drafts] QPACK decoder stream buf… afrind
Re: [quicwg/base-drafts] QPACK decoder stream buf… Dmitri Tikhonov