IETF Logo Mail Archive

Re: [quicwg/base-drafts] Remove PRIORITY (#2924)

Robin Marx <notifications@github.com> Tue, 23 July 2019 10:06 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 603C7120147 for <quic-issues@ietfa.amsl.com>; Tue, 23 Jul 2019 03:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 zr3IE9eGGIJT for <quic-issues@ietfa.amsl.com>; Tue, 23 Jul 2019 03:05:58 -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 AA42512010C for <quic-issues@ietf.org>; Tue, 23 Jul 2019 03:05:58 -0700 (PDT)
Date: Tue, 23 Jul 2019 03:05:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563876357; bh=NKxDpjxew0YkJyDTbcqo6D86E5ugV9ljymP2hz6Y7hQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dQrjoC5Sqf3Cf+GOR8L2yEpZzH+MTPMRGuCo+RjiPFxuBT/CoYwFSLJXrHGuK9HKa eFDiakNu40te3XpDqF00qMBbpqNuhL0Hr0Ypq6bXpVhjIETXJF739g1Huy3F82wU9F grB5Vr9I1UrtmdCJgA94w91yMcGWrUVsQnePHoT4=
From: Robin Marx <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4NB5KXJ5GI3LPCSRF3IQHILEVBNHHBYGBYPM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2924/514144677@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2924@github.com>
References: <quicwg/base-drafts/issues/2924@github.com>
Subject: Re: [quicwg/base-drafts] Remove PRIORITY (#2924)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d36dc059df66_64bd3fb1e4ecd968149597"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: rmarx
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/Dz86HDnOJT2Zr56c_13ZDNj2HIA>
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: Tue, 23 Jul 2019 10:06:01 -0000

I really like your signal/waveform analogy Lucas, so I'll try to use it to make my point as well.

You view the removal of client-side signaling as just lowering the amplitude of the waveform. I view it more as taking too few samples to still satisfy the Nyquist theorem. In other words: we are indeed still able to reconstruct _something_ from the signals server-side, but the result doesn't (necessarily) look like the original anymore. This loss of information might be acceptable in some/most cases (important: acceptable, not optimal), but can be detrimental in an (important) subset of setups. 

I am mainly worried about the impact on more advanced recent and proposed features, such as preload/prefetch, async/defer and priority hints. These features were explicitly added to improve (load) performance and they are difficult to adhere to without client-side scheduling. I predict that removing prioritization from H3 without a fallback will lead to performance-minded people having to provide 2 different versions of their sites, 1 for H2 and 1 for H3. For example, the H2 version can have async/defer/preloads mentioned in the <head> of the HTML, the H3 version without priorities probably shouldn't. 

To also address your last "devil's advocate" from the other thread (https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513989715): yes, FIFO willl work and won't be super-detrimental in most cases. However, it's been stated several times before that for H3 (and QUIC) to be successful and find adopters, it needs to have demonstrably better performance than H2/TCP. You will not get that from a simple FIFO and also not from more complex server-side-only heuristics based on user-agent + content-type (your "low amplitude" signal). If you want H3 to outperform (best-in-class) H2, I feel we need **more** signals, not less. And yes, much of H3's perf benefits will come from QUIC and 0-RTT etc. but even the Google paper quotes just 8% (at best) and those benefits are not limited to QUIC (e.g., TCP fast open, TLS 1.3 early data). The current discourse seems to be you agree that the performance would be worse than for H2, but that that's not an issue. I have a hard time understanding that point of view. 

In summary, I do not feel that server-side-**only** prioritization is a workable fallback solution (https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513987999) (except maybe for implementations that were broken to start with... https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513983658) and while sticking our heads in the sand on this might allow us to "ship" QUIC and H3 "on schedule", I doubt the value of that in the long run. I'm fine with removing H2's priority system, but shipping H3 without a decent replacement is [madness](https://resize.rbl.ms/simage/https%3A%2F%2Fassets.rbl.ms%2F17438671%2F980x.gif/980%2C880/ILf9gZME9keiTx7T/img.gif). 

-- 
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/2924#issuecomment-514144677

v2.23.0 | Report a Bug | By Email