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

Lucas Pardue <notifications@github.com> Fri, 27 July 2018 19:30 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 EFD80130DCB for <quic-issues@ietfa.amsl.com>; Fri, 27 Jul 2018 12:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.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_HI=-5, 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 aVxPvLyydx4s for <quic-issues@ietfa.amsl.com>; Fri, 27 Jul 2018 12:30:29 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0438130DCA for <quic-issues@ietf.org>; Fri, 27 Jul 2018 12:30:28 -0700 (PDT)
Date: Fri, 27 Jul 2018 12:30:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532719827; bh=YbQ4CpXAyz/o7DWySTbeecPX1VNLVbfsVlfmT2qVc/w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Doj9eY77aXz89JcQQ6lX0kxAuNfAIUFY+gtyIndiLRXb3K0wUw/mxxll6wOvxdblj AfRDFrT+rJWQdKTj4mweQjei5P7cqlQorvva1KI6y4ufK5RD874Ww9Fg21XtzWgrGK X/HuM7+jemb9zk/AgdtZYvPWI6H+wTF7fb/LSav8=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5fdfc724b48adfb896aec0134d0899436714008c92cf00000001177334d392a169ce148a3cb6@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/408517340@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_5b5b72d3b365a_4fc83faa7f0d45bc10802c"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/JwDbMZtIhIfD0G5O-YhblnH4Unw>
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: Fri, 27 Jul 2018 19:30:31 -0000

I think the current stream design is good for the conventional HTTP case. I think that more specialised HTTP applications, where the resources are more self-describing can benefit from alternate designs. To paraphrase some of the above discussion, a request for a DASH initialisation segment can ellicit a bunch of PUSH_PROMISEs for media segments (easily generated because they are predictable, so minimal HOL blocking). Soon after, media segment body data is delivered on a new type of HTTP/QUIC server-initiated unidirectional stream that delivers segment body on STREAM frames. Some time later, response headers can be delivered on yet another new stream type, to be used for caching etc.

This allows the media segment data to be fed directly into a player pipeline closer to the rate of delivery.

-- 
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-408517340