IETF Logo Mail Archive

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

Kazuho Oku <notifications@github.com> Sun, 21 October 2018 21:55 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 16A191293FB for <quic-issues@ietfa.amsl.com>; Sun, 21 Oct 2018 14:55:11 -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 tuRfbHMIB8Q6 for <quic-issues@ietfa.amsl.com>; Sun, 21 Oct 2018 14:55:09 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E16F120072 for <quic-issues@ietf.org>; Sun, 21 Oct 2018 14:55:09 -0700 (PDT)
Date: Sun, 21 Oct 2018 14:55:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540158908; bh=ZilRPnc4dVG1rXIRxE20e4r0e6Vo3skccIA7IHG8E1M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=haJ/4sD+24B9bzhQ6GGul3z8DQ6DVa5tFU0Ajc0v0Nob2yWH3Wr6mCX76PipfiMmR E4UsScwmPbmxdrnOxmMv/rqPv1TF+xglfNsiXxbHuu4IlwlBkzV1Y9UNUW1pKIvAPG C1NA9Qq2kL5fNPDmrqWlMCg/w1VcPS1Z77vpCKWU=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab07c8e8cdf642fe5dbe9e56e30db5d3bd326f8c3f92cf0000000117e4b7bc92a169ce16286866@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/431707592@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1885@github.com>
References: <quicwg/base-drafts/issues/1885@github.com>
Subject: Re: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bccf5bc4e3bf_88a3ff2d3ad45c02699893"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/HgtkDvfCTg3jOuv543-SGcvz7jE>
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: Sun, 21 Oct 2018 21:55:11 -0000

@ianswett H2O is capable of sending server-timing headers as trailers.

However, regardless of the use case, any proxy (including edge servers) that can forward trailers need to use length-delimited DATA frames when forwarding a chunked response, because it cannot tell whether trailers exist until receiving all the response body.

> Clearly our code will end up having to support specified lengths due to interop and the small number of cases(push and trailers included) that we support.

Agreed. This discussion is not about simplifying the decoder. It's about simplifying the encoder used by certain endpoints (as well as reducing the network overhead in a small degree).

-- 
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#issuecomment-431707592

v2.46.0 | Report a Bug | By Email | System Status