Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E376130E3B for ; Mon, 6 Aug 2018 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQqv-EUMZUgy for ; Mon, 6 Aug 2018 07:00:46 -0700 (PDT) Received: from o4.sgmail.github.com (o4.sgmail.github.com [192.254.112.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7F2130E23 for ; Mon, 6 Aug 2018 07:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=teKgqIVkO8zujL6MyXHBl6tpLas=; b=O3t1/xeE3qwQ94WV 9Mp5NcedfYaABuZh733ZWrvS6ZHzOhUObhqY9aTbKDUrRF0hS2ZXI5oQm9Ydt6KK 8ES5FrQU2SIMpCT56HGVsdcXziHViDIm/90A75Id8g60cJig7NP2pxUiboY7TTZ3 UTolNsw4zJejOXM9TvscL71Xpiw= Received: by filter0951p1las1.sendgrid.net with SMTP id filter0951p1las1-25488-5B68548C-D 2018-08-06 14:00:44.152517921 +0000 UTC m=+1006354.483803355 Received: from github-lowworker12-cp1-prd.iad.github.net (unknown [192.30.252.42]) by ismtpd0023p1mdw1.sendgrid.net (SG) with ESMTP id eDOQfVccRzKuHZrDmVbEtQ for ; Mon, 06 Aug 2018 14:00:44.007 +0000 (UTC) Received: from github.com (localhost [127.0.0.1]) by github-lowworker12-cp1-prd.iad.github.net (Postfix) with ESMTP id 965AF40D2F for ; Mon, 6 Aug 2018 07:00:43 -0700 (PDT) Date: Mon, 06 Aug 2018 14:00:44 +0000 (UTC) From: Dmitri Tikhonov Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Length-prefixes and flow control (#1432) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5b68548b946cf_2dde3fe6180be620600b9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: dtikhonov X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2dcrzyOLIqT1GOoaLtxiWjlEMGtoM6JMT7Wh fBEoA1QraD2vka7RlE0KsBSKN7ucxSC88ZWZbld3Yd3RbKYGNZp+hECX1SbOtrRm7ompT3us9bQQHS ZKc+/I1pHoKmcn12RTmm7RS31UDdQGCYw2py2vYoet1mkBHYK1Q+EXn3hfN+U0Xyu5vCOXIfq/aYCq 0= Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.27 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 14:00:49 -0000 ----==_mimepart_5b68548b946cf_2dde3fe6180be620600b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'd like to make another comment related to the EOS symbol. The QPACK encoding process produces two outputs: the encoder stream instructions and the header block. Now that the encoder framing has been removed, the encoder instructions can be written directly to the stream, while the associated header block must be buffered because we don't know its length [1,2]. We can avoid buffering of the header block by introducing an _End of the Header Block_ instruction at the cost of one byte. The header block has just a few instructions and can easily accommodate another one. This would also force our hand with regard to the Base Index: we'd have to pick it immediately. On the other hand, it can make the design simpler: just set it to the same value as the Largest Reference. This will offset the cost of the new EOS instructions, as Base Reference no longer has to be transmitted. For this to work, we'd have to bring back _CONTINUATION_ frames, which seem to have had been designed exactly with this use case in mind. Without them, we still have to buffer to calculate the size of the _HEADERS_ frame. For background, see issue #76 and the [httpbis PR #548](https://github.com/http2/http2-spec/pull/548). Needless to say, I do not agree with the rationale behind removing CONTINUATION frames from QUIC. Footnotes: 1. I am aware of the deadlock hazard brought on by writing the header block and the encoder stream concurrently. The assumption is that an implementation that writes to packets directly has the logic to do this right. 1. One alternative is to pre-calculate the encoded length of the header block. This is unworkable because it a) essentially doubles the work; and b) causes buffering of unencoded header fields. -- 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/1432#issuecomment-410717845 ----==_mimepart_5b68548b946cf_2dde3fe6180be620600b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd like to make another comment related to the EOS symbol. The QPACK e= ncoding process produces two outputs: the encoder stream instructions and t= he header block. Now that the encoder framing has been removed, the encode= r instructions can be written directly to the stream, while the associated = header block must be buffered because we don't know its length [1,2].

We can avoid buffering of the header block by introducing an End of = the Header Block instruction at the cost of one byte. The header bloc= k has just a few instructions and can easily accommodate another one. This= would also force our hand with regard to the Base Index: we'd have to pick= it immediately. On the other hand, it can make the design simpler: just s= et it to the same value as the Largest Reference. This will offset the cos= t of the new EOS instructions, as Base Reference no longer has to be transm= itted.

For this to work, we'd have to bring back CONTINUATION frames, = which seem to have had been designed exactly with this use case in mind. W= ithout them, we still have to buffer to calculate the size of the HEADE= RS frame. For background, see issue #76 and the httpbis PR #548. Needless to say, I do not agree with the= rationale behind removing CONTINUATION frames from QUIC.

Footnotes:

  1. I am aware of the deadlock hazard brought on by writing the header bloc= k and the encoder stream concurrently. The assumption is that an implement= ation that writes to packets directly has the logic to do this right.
  2. One alternative is to pre-calculate the encoded length of the header bl= ock. This is unworkable because it a) essentially doubles the work; and b)= causes buffering of unencoded header fields.

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_5b68548b946cf_2dde3fe6180be620600b9--