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

grmocg <notifications@github.com> Fri, 27 July 2018 20:34 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 47CB7130E2F for <quic-issues@ietfa.amsl.com>; Fri, 27 Jul 2018 13:34:52 -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 p5il-807sIaO for <quic-issues@ietfa.amsl.com>; Fri, 27 Jul 2018 13:34:49 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53B4130E24 for <quic-issues@ietf.org>; Fri, 27 Jul 2018 13:34:49 -0700 (PDT)
Date: Fri, 27 Jul 2018 13:34:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532723688; bh=AbX6ORHZ6WLfJXlyZYrU6oa/dRbp6jS6mJwOh4EmasU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xm45wGLzVYS2KUp4LzFur7cJc48uAlMihFu9hnHZCcRTbAYHuLj4kzIALzItEEFBg TfUKRSRD5KGQwuSZLOm96Irz+1JRx4MSnH9JK0otaIJNvpSiD+hlg+kD4wN0+DhhuL WQD5v/o2VGp9jxiUZskf/NGFrngCTCs+C1iuoePk=
From: grmocg <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab502231c6f4039e0ad1c86f80249837228f5869ef92cf00000001177343e892a169ce148a3cb6@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/408531743@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_5b5b81e8e55c5_50db3fafce6d45bc102486"; 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/GXxS0yO5U5JCyc_Q_c3alaMUSAk>
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 20:34:52 -0000

@LPardue 
Yup. 

I think/hope that we can come up with a cheap and standard way of representing the end of the initial headers to enable these usecases.
And example was to have a new frame type (at the 'http' layer) which allows us to say the offset of the metadata for a few RTTs until we know a packet containing it has been received. 

 I'm not worried about in-line metadata, since that is arguably 'payload' in a world where we can do stream-groups and multiple response streams (which would be arguably more flexible than a single response with multiple metadata segments for header-size-ish metadata).

@MikeBishop 

In my estimation, this isn't just a 'server push' issue, as one would really want to do the same thing on ingestion (uploading), not just playback (downloading). It becomes an HTTP mapping issue (whether for quicv1 or quicv2) since it impacts not just push, but also GET/PUT, and should fit into whatever prioritization stuff is happening as well. 

Consider that one of the bigger issues with video playback (and rebuffers), especially on browsers (but also on android/ios apps), is "application" self-contention. A page/application/domain makes requests for HTTP objects but, due to the lack of coordination (today) between the video uploading/downloading stuff (most often not HTTP today for low-latency stuff) and the non-video HTTP stuff, the bandwidth estimate becomes incorrect, the buffer drains prematurely, and you have the video transfer (which expects at least a certain bitrate over short time periods), much to user chagrin.

Anyway that is part of the thought process!

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