Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)

Igor Lubashev <notifications@github.com> Mon, 20 May 2019 16:52 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 6E53712004E for <quic-issues@ietfa.amsl.com>; Mon, 20 May 2019 09:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Level:
X-Spam-Status: No, score=-3.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_IMAGE_ONLY_32=0.001, 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 qWpxn-KQO_gc for <quic-issues@ietfa.amsl.com>; Mon, 20 May 2019 09:52:44 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C3A12004C for <quic-issues@ietf.org>; Mon, 20 May 2019 09:52:44 -0700 (PDT)
Date: Mon, 20 May 2019 09:52:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558371163; bh=Pvddhq7CpBW9ujLX8IWlkZYNioi8PeAHrhL1XmyJtJ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QmdrjpbbHUsmyIAoSZLDSoaTKqWu0DrxuRVSViSrlc1CpCGuRRv4EXSoHnRPQGhD+ 7B/P5G90e0frieTFLm2ldvaO+3oEGluChAVYlDdKHCxdqouGHY311l++QmvZYEGCO8 /l4J+YCi18vKxGv6jSHRUjnG75Ve4hw5DWVjeFmk=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5PTJYLOCMQFIW4DYV26AG5XEVBNHHBU6PCKA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2700/c494067457@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2700@github.com>
References: <quicwg/base-drafts/pull/2700@github.com>
Subject: Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ce2db5b6be31_65ce3fd8582cd95c4193d3"; 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/JbLnRwxbJBgiTnTw07S7P1FqPAY>
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: Mon, 20 May 2019 16:52:46 -0000

@rmarx, I would not say that odd priority values _represent_ odd concurrency level 3.  You could implement @pmeenan's "concurrency level 3" that way.  But the idea is that you do not need "concurrency level 3" as a special case to think about.

There are just two criteria:

1. Priorities:  Elements of the higher priority 100% preempt elements of the lower priority.

2. Concurrency: Elements of the same priority share bandwidth.  Serial elements need to be downloaded to completion one at a time, while concurrent elements need to be downloaded concurrently.  There is still a question of how serial and concurrent elements share bandwidth.  There is a proposal that concurrent elements get 50% of the bandwidth as a group.  The alternative is that concurrent elements group gets a percentage proportional to the number of concurrent elements in at that priority level. Both of these alternatives seem "hacky" as they possible do not give the client sufficient control for bandwidth sharing.  I have some proposal and will share it on the list (the PR comment does not seem like the right place for it).

-- 
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/2700#issuecomment-494067457