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

grmocg <> Thu, 26 July 2018 01:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A238B130F58 for <>; Wed, 25 Jul 2018 18:58:28 -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 DA7zqLYINMMD for <>; Wed, 25 Jul 2018 18:58:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B67E8130F55 for <>; Wed, 25 Jul 2018 18:58:26 -0700 (PDT)
Date: Wed, 25 Jul 2018 18:58:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1532570306; bh=AZIPcv6xsLr7QP4NDQhn9QbLbqINIXJD0lTwcKrjSJQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=P1tmzLX05+sHJoPG4lfiofD5pCB654ZqXZcuDRE1cgu2y6evzEWX8jdw96tv1Rqt0 QkeffgWo2tnoPpbyj/2owLjtdlO3T+BhljT4iSyTWVqIft0N/fKFFq8rC2mSJIIRbF lMV6TNog5yd4oi2KGhy+CgRNQYVQQ1JInqrp7UdI=
From: grmocg <>
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_5b592ac2141a7_5b923ff4342d45c041613"; 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
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 01:58:29 -0000

Http has explicit control for caching, scales to millions, and is already
in use by the application (e.g. for getting the list of videos, thumbnails,
etc), which would otherwise have to deal with contention between multiple
connections (something which decreases the accuracy of the bandwidth
estimate, and would cause rebuffering if not controller for).

Http offers a mechanism (via byterange requests on named resources) to
'heal' uploads/broadcasts if there should be an interruption, reconnection,
server restart,

Http offers all of the semantics we want except partial reliability, which
is what this is about!

On Wed, Jul 25, 2018, 6:33 PM ianswett <> wrote:

> Q: What's the benefit of HTTP here? It seems like you might want RTP
> and/or WebRTC over QUIC?
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <>,
> or mute the thread
> <>
> .

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