Re: [quicwg/base-drafts] HTTP/3 Zero-weighting (#2723)

Igor Lubashev <notifications@github.com> Sat, 18 May 2019 20:03 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 970FD1200B2 for <quic-issues@ietfa.amsl.com>; Sat, 18 May 2019 13:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 IPl-7w6CkywH for <quic-issues@ietfa.amsl.com>; Sat, 18 May 2019 13:03:03 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E27C1200F7 for <quic-issues@ietf.org>; Sat, 18 May 2019 13:03:03 -0700 (PDT)
Date: Sat, 18 May 2019 13:03:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558209782; bh=NtVrm4syRAJdXvNxH80Wsj5E+rpw/w3rMm4tizt79yk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LxUXYhXf4UsWiJUojAwj0/bHmMOkKdvq/p+YsgF/jxdl9sLBZgknc0G2zU3a1PjoH aRQn5hYDNIFoSkIgrzY/iIwDtObn8G9l9VNhbOVPZEK9YSQDULUAGI5qnWzVOY4cLr j692Sp0zp5yDHtuvODISUM33jTe+k0vecWb34idM=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYJLDRZTFK4DM3DISF25WLXNEVBNHHBVEEO5I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2723/c493703452@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2723@github.com>
References: <quicwg/base-drafts/pull/2723@github.com>
Subject: Re: [quicwg/base-drafts] HTTP/3 Zero-weighting (#2723)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce064f6863c6_353e3faf9bccd96012048de"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/3gZCLwkMoB8DWthF2V8ETLVqOBs>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 18 May 2019 20:03:06 -0000

The situation I would like to be able to cover is a page with several videos (or animated gifs) and a few async scripts.  You want these videos to start playing asap and all together (before scripts load), but you do not want to wait till videos are completely downloaded to begin loading those async scripts (which should load serially).

> As long as there are children with non-zero weights: divide the node's bandwidth over those children based on their weights

So what happens to sequential scripts? They shall wait till all videos are downloaded?


> If there are only children with zero weight left: all bandwidth goes to the child with the lowest ID that can make progress

I do not like creating arbitrary priorities where none are warranted. It is best not to lie to the server and let it pick its own priority, if it is all the same to the User Agent. For example, if there are multiple zero-weight children, the server may choose to deliver whatever object is fully available in memory rather than deliver 80% of an object with the lowest ID first and only then start sending the fully-available object.

-- 
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/pull/2723#issuecomment-493703452