Date: Mon, 22 Jul 2019 15:08:23 -0700
From: Robin Marx <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJK6EBO24BB2G75CGLGN3INTFPEVBNHHBYFV37I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2922/c513973587@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2922@github.com>
References: <quicwg/base-drafts/pull/2922@github.com>
Subject: Re: [quicwg/base-drafts] Remove PRIORITY (#2922)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5d3633d7a072_76153fdd09ccd9601239160";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/lWJg3qOiNLap5LRGef5OBK1RFQA>


----==_mimepart_5d3633d7a072_76153fdd09ccd9601239160
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I understand the appeal of this proposal, but I don't agree that simply cutting priorities without replacing them with something else is the right way forward. 

I don't see how this PR actually solves anything... it will allow us to ship HTTP/3 sure, but it will be (even more) difficult to use correctly in practice. This puts the burden of figuring out prioritization fully on the servers, and [we've seen how well that will go in practice with H2](https://github.com/andydavies/http2-prioritization-issues). 

I would also like to see some more detailed explanation on the statement in the httpbis session just now (which was a bit more strongly worded than the original post in this thread):

> prioritization is important but we don't need signaling for prioritization

I'm not sure I follow this... Are we suddenly claiming that the server does not need client-side information anymore, which is the opposite of the reasoning behind H2's setup? Do you feel you can do good server-side prioritization without client-side signaling? What would that look like? Combining content-type with user-agent? 

---

In essence, I feel that if we remove tree-based priorities, we **must endorse another solution** (e.g., patrick meenan's setup, kazuho's http-header based solution) and standardize that alongside H3. I fear not doing this will lead to a mess that will be difficult to recover from (i.e., if we standardize the signaling part later on, it will be difficult to find enough uptake, which was one of the main goals on Ian's slides).  




-- 
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/2922#issuecomment-513973587
----==_mimepart_5d3633d7a072_76153fdd09ccd9601239160
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p>I understand the appeal of this proposal, but I don't agree that simply cutting priorities without replacing them with something else is the right way forward.</p>
<p>I don't see how this PR actually solves anything... it will allow us to ship HTTP/3 sure, but it will be (even more) difficult to use correctly in practice. This puts the burden of figuring out prioritization fully on the servers, and <a href="https://github.com/andydavies/http2-prioritization-issues">we've seen how well that will go in practice with H2</a>.</p>
<p>I would also like to see some more detailed explanation on the statement in the httpbis session just now (which was a bit more strongly worded than the original post in this thread):</p>
<blockquote>
<p>prioritization is important but we don't need signaling for prioritization</p>
</blockquote>
<p>I'm not sure I follow this... Are we suddenly claiming that the server does not need client-side information anymore, which is the opposite of the reasoning behind H2's setup? Do you feel you can do good server-side prioritization without client-side signaling? What would that look like? Combining content-type with user-agent?</p>
<hr>
<p>In essence, I feel that if we remove tree-based priorities, we <strong>must endorse another solution</strong> (e.g., patrick meenan's setup, kazuho's http-header based solution) and standardize that alongside H3. I fear not doing this will lead to a mess that will be difficult to recover from (i.e., if we standardize the signaling part later on, it will be difficult to find enough uptake, which was one of the main goals on Ian's slides).</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/2922?email_source=notifications&amp;email_token=AFTOJK33PLRNOVWJ4OTQ47LQAYVVPA5CNFSM4IF3PEFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RJ2UY#issuecomment-513973587">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK27DCQ7SHNYQWF6RL3QAYVVPANCNFSM4IF3PEFA">mute the thread</a>.<img src="https://github.com/notifications/beacon/AFTOJKZVI4ID6I664BILR5LQAYVVPA5CNFSM4IF3PEFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RJ2UY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2922?email_source=notifications\u0026email_token=AFTOJK33PLRNOVWJ4OTQ47LQAYVVPA5CNFSM4IF3PEFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RJ2UY#issuecomment-513973587",
"url": "https://github.com/quicwg/base-drafts/pull/2922?email_source=notifications\u0026email_token=AFTOJK33PLRNOVWJ4OTQ47LQAYVVPA5CNFSM4IF3PEFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RJ2UY#issuecomment-513973587",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5d3633d7a072_76153fdd09ccd9601239160--