[quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)

Ryan Hamilton <notifications@github.com> Thu, 18 October 2018 23:06 UTC

Return-Path: <noreply@github.com>
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 1A7C4130E41 for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 16:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 9BTBOhMmsACd for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 16:06:14 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3DF130E23 for <quic-issues@ietf.org>; Thu, 18 Oct 2018 16:06:13 -0700 (PDT)
Date: Thu, 18 Oct 2018 16:06:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1539903972; bh=pCRNfLWNU+W1bn2+m47d+nyp3G/1RR8/d6drhr1jl/k=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=jiw2DA8SsvZaj9GNacIBqSIs4ipkf26/YYBUr8ekg/BSh/8jBpugSGtBSSjqwE+DI tytXnts+D/JX18Gzc2S3NF0f46oG8+rnBAgly3Dyrn0EU+Rkn/UxCXAUQr9KR1H2Yz achPyKgaDB77PoddliTg1ve4UJoQcJpAmibSbAiU=
From: Ryan Hamilton <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba6e67af891ee15071400546777b958d0dbec6ed592cf0000000117e0d3e492a169ce16286866@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1885@github.com>
Subject: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bc911e4a2ea0_2e173ffc9bad45bc11084"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ynL5VUsVvKNlxgO_nkqlLI1Dc9E>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 23:06:16 -0000

In the common case of a long response body that is dynamically generated, it is not possible to know the full length up front. Instead, the body is often read in chucks from some backend/data source and written to the wire as it's available. Since response bodies need to be encoded in DATA frames with an explicit length this typically means splitting the body into numerous chunks. Instead if would be more efficient if we could set a length of "until end of stream" (encoded as 0 or some such) which would allow the sender to write a single DATA frame header and the simply send the entire body without additional framing.

HTTP/2 explicitly tries to avoid overly long frames. This is a feature for HTTP/2 in which the frames for multiple streams are sent on the same in-order sequence of bytes, so a long frame potentially introduces head of line blocking for other higher priority data. But for QUIC there is no such concern since these DATA frames are all within the same stream.

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