Re: [quicwg/base-drafts] Possible HoL blocking due to co-mingling payload and metadata (header) address space. (#1606)

Lucas Pardue <> Thu, 26 July 2018 08:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F602131012 for <>; Thu, 26 Jul 2018 01:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w4svo5S_fBjY for <>; Thu, 26 Jul 2018 01:25:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C48C131007 for <>; Thu, 26 Jul 2018 01:25:45 -0700 (PDT)
Date: Thu, 26 Jul 2018 01:25:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1532593544; bh=L0wbX4qubsd5N9rdKaS1IJQKT6ZZK2PbbMFGxvETQHs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=umDYU6LIe9+Mx8uBAfKxSKQXuU2IDc97jCwfycTTpioimj0LletixwAFfE9HcaBnb WHw6t0QdIfESzrPGOy9xVHoQ2npw5TW0N+rljNbfhwbvdzIKI+CpovpIRVa0uIzVDJ n4yLDiYy1T/YF1XisWzw4EP53h31oGkJ+uP1Ta8k=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1606/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Possible HoL blocking due to co-mingling payload and metadata (header) address space. (#1606)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b5985886e43d_1e7c3fe0a54d45c0369815"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
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: Thu, 26 Jul 2018 08:25:47 -0000

@martinthomson thanks for the explanation feedback. Since it took me time to digest what you said let me echo back my interpretation: for a more loosely coupled interaction mode, the use of DATA frames prevents random access to the QUIC stream because there'll be HTTP/QUIC frame headers at unknown locations. 

One approach, therefore, might be to carry bodies directly in STREAM frames, which starts to sound like GQUICs approach. The difference being that we might avoid use of stream ID's directly and use some other token to correlate headers and bodies.

In a partial reliability world, with the above design lost STREAM frames are ok. They result in HTTP body gaps, that can be skipped or repaired (say by byte-range request as @grmocg suggests). We implement a design like this today in our multicast QUIC prototype.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: