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

Martin Thomson <notifications@github.com> Thu, 26 July 2018 01:57 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 475D4130F43 for <quic-issues@ietfa.amsl.com>; Wed, 25 Jul 2018 18:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
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: 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 ekEtm9ayCqqd for <quic-issues@ietfa.amsl.com>; Wed, 25 Jul 2018 18:57:05 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EAB127332 for <quic-issues@ietf.org>; Wed, 25 Jul 2018 18:57:05 -0700 (PDT)
Date: Wed, 25 Jul 2018 18:57:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532570224; bh=ZP9myeTp6bOt+uU6VCeqbmc7rpBMKGTz2DAf04XutEE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sSz6GyBGnblDbzsZSJWdIyTsS7AaZsYtQ1WZz7yYeDXRCd5ECFou615clWGZqcwSb 2Z6vc2Utk7UqB7zQDud2bKac0EbQrVxRtQYvQUuseA5qoD/xXz5Ivnm11ECJcLhJj6 uqwMNoURw9xhcqF+kKkd/bScO7cTyFCSgPsV73g4=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5335e0a6918eff63b3110d69f2949918c7ece8a792cf000000011770ec7092a169ce148a3cb6@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1606/407951291@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1606@github.com>
References: <quicwg/base-drafts/issues/1606@github.com>
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_5b592a703daf_66423fae8c4be61c72256"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/gWOM5Qes3rO7eBgP6eSsNNiB2O0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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, 26 Jul 2018 01:57:07 -0000

I'm inclined to suggest that this is something that could be addressed in an extension.  Imagine that both peers negotiate a new interaction mode whereby request and response bodies are carried on other streams.  (For @LPardue: that new stream couldn't use DATA frames though, or you lose random access, not knowing where the frame headers are inserted.)  Establishing which stream maps to which request is tricky, but probably able to be resolved in a way that meets the requirements.  I suspect that you can't avoid having at least *some* metadata, but it might be possible to use a signaling mechanism for that that can be isolated from the worst of the HOLB.

The OP suggests that metadata might not be important, which suggests that maybe this isn't as much HTTP as is claimed.  In some ways, the more useful this protocol is for this sort of use case, the less it resembles HTTP.  We should explore that some more.

I realize that there are benefits to this being the standardized approach for HTTP, but we'd need to resolve the question of similarity first.  After that, we need to recognize that the structure of the current design is intentional and addresses real issues (though for some, that depends on how much you believe server push to be relevant).

-- 
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/1606#issuecomment-407951291