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

grmocg <notifications@github.com> Wed, 25 July 2018 20: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 2E06C130F0B for <quic-issues@ietfa.amsl.com>; Wed, 25 Jul 2018 13:55:49 -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 NBkyIwW7qJH5 for <quic-issues@ietfa.amsl.com>; Wed, 25 Jul 2018 13:55:47 -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 EA01F130EC6 for <quic-issues@ietf.org>; Wed, 25 Jul 2018 13:55:46 -0700 (PDT)
Date: Wed, 25 Jul 2018 13:55:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532552146; bh=Qw9oXbKu8FQMrJMy7aAX8oXZ1xHoWoXrmKBhRVntMS8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=QbzThg1e1bMt5A/ziVyfwOAp4G/FVMzeQuNbLc5U/XkFkkhTpJSsjxpd11nhWF/Wy dcgNS/VmzYGRfxOWBwC2O8UtkamPIJ/rt1eVlENNhtQ+wf8di4D14Vk90zafThGYrS sV3i0t0IPzOqNZtgOe4jwdQo0eYpWue1SGJBqqB8=
From: grmocg <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abec8cbc02c8a4ff1e8c0a7632958f932ff3f63e0e92cf000000011770a5d192a169ce148a3cb6@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@github.com>
Subject: [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_5b58e3d1efa41_84d3fe5b94be61c103394"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: grmocg
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/oRSDxpeTeQ8Cery5R8H60c4Sz34>
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: Wed, 25 Jul 2018 20:55:56 -0000

In the 'partially reliable http' use-case, e.g. an interactive (VC-like) 'video protocol', **the co-mingling of the payload and metadata (header) address space on the QUIC stream prevent interpretation of payload data until all metadata has been received in cases which attempt to use the address space to assert framing** (e.g. I know that the data at any location where n % k == 0 is the start of a record). 

This method of framing is unavailable (until all headers have been received) with QUIC as it is today since the size of the metadata the client will receive is unknown (it might be encoded by a different compressor, e.g. via a reverse proxy) to either the client or sender, and since the address space of metadata and payload is co-mingled.

In other words, in cases where the client knows the relationship of the requests/responses (for instance with a server push response to a particular request) and so doesn't need the headers immediately, it is advantageous to have an address space for payload that starts with a known, constant value.

Consider the following:

1. A client requests video of a particular codec, size, bitrate, etc.
2. The server replies by sending a number of server push streams in response to that request., likely within a 'stream group' should such a thing come into existence in QUICv2.
3. For streams which arrive after the first server push'd stream, the type of the data is , and can be interpreted by the application immediately, even when received out-of-order and/or non-contiguously.

It would be expected in such a use-case to have a large number of server push'd 'responses' referring to byte-ranges of files on a server/proxy/cache. The client would likely establish a few requests to which the server would never directly respond (it would instead server push responses to those 'requests'), e.g. the client would request playback of a 5MB/s 264 bitstream, and the server would push byteranges of a file containing (at least) the elementary stream.

Note that the headers on the pushed streams will be useful upon receipt for applications running on a framework (e.g. a browser) which may wish to cache/store and which (likely for security reasons) doesn't offer the application the ability to assert the data should be stored with URL X/ETAG Y. 



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