Subject: PRIORITY extension

From: <[email-masked]>
Date: Sat, 12 Jul 2014 20:46:55 +0000

As far as I can tell, everything in h2-13 related to PRIORITY is completely optional (please correct me if I'm wrong).

I've repeatedly seen arguments against adding anything optional to the spec. So why does PRIORITY get a pass? If it's truly optional, it could easily be moved to a separate RFC as an extension.

So, why not move PRIORITY to an extension? It would make the main spec smaller and cleaner.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 Jul 2014 13:13:03 -0700

> So, why not move PRIORITY to an extension? It would make the main spec smaller and cleaner.

A multiplexed protocol doesn't work without prioritization.  Or
rather, it ends up worse than what we currently have.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 13 Jul 2014 21:32:20 +0000

In message <CABkgnnUcP9QToaDru75nYqgy2E=[email-masked]>, Martin Thomson w
>rather, it ends up worse than what we currently have.

But we agree that it is optional, right ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: David Krauss <[email-masked]>
Date: Mon, 14 Jul 2014 07:41:09 +0800

On 2014–07–14, at 4:13 AM, Martin Thomson <[email-masked]> wrote:

> A multiplexed protocol doesn't work without prioritization.  

Prioritization is a server implementation detail. The question is about a standardized client interface to the server-side priority-weights on a particular connection, which is far narrower. 

Many applications (clients and servers) will have no use for PRIORITY. As PHK says, it’s de-facto optional no matter what.

---

From: David Krauss <[email-masked]>
Date: Mon, 14 Jul 2014 07:55:06 +0800

> I've repeatedly seen arguments against adding anything optional to the spec. So why does PRIORITY get a pass? If it's truly optional, it could easily be moved to a separate RFC as an extension.

I’m in favor.

Clients wishing to send PRIORITY should know whether the server is just going to ignore it. It’s a good signal to use another prioritization strategy, for example by reducing concurrency (start streams later).

Also, it’s had the most churn of any part of the spec and practical experience will take more time. Extension status will enable faster evolution.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 13 Jul 2014 20:41:48 -0400

The whole point of h2 is a prioritized, muxxed protocol with improved
connection handling.

Let's complete that work.

-P

On Sun, Jul 13, 2014 at 7:55 PM, David Krauss <[email-masked]> wrote:

> > As far as I can tell, everything in h2-13 related to PRIORITY is
> completely optional (please correct me if I'm wrong).
> >
> > I've repeatedly seen arguments against adding anything optional to the
> spec. So why does PRIORITY get a pass? If it's truly optional, it could
> easily be moved to a separate RFC as an extension.
>
> I’m in favor.
>
> Clients wishing to send PRIORITY should know whether the server is just
> going to ignore it. It’s a good signal to use another prioritization
> strategy, for example by reducing concurrency (start streams later).
>
> Also, it’s had the most churn of any part of the spec and practical
> experience will take more time. Extension status will enable faster
> evolution.
>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 00:53:03 +0000

In message <[email-masked]>, Patrick McManus 

>The whole point of h2 is a prioritized, muxxed protocol with improved

I'm sorry to be pedantic about this, but that's not even close to
what our charter says.  It may be a _way_ to fulfill the charter,
but it is not "the whole point".

I support moving prioritization to an extension, for the simple
reason that a lot of uses will not need prioritization at all and
because I have not seen credible evidence for the quality of the
proposed scheme.

Making it an extension means we don't have to finish it at the same
time as the base HTTP/2 spec, and that we can replace it with
something better later on.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 14 Jul 2014 09:58:17 +0900

connection handling.
> Let's complete that work.

I couldn't agree more.
Removing PRIORITY is really bad idea.

Best regards,
Tatsuhiro Tsujikawa

---

From: Patrick McManus <[email-masked]>
Date: Sun, 13 Jul 2014 21:02:56 -0400

> but it is not "the whole point".

I spoke of a specific item - h2, not the wg or the charter. I don't need or
care about another charter discussion.

I need an open standard for a prioritized, muxxed, h2 with improved
connection handling. And we've got a decent one with h2-13. Let's ship it
instead of running around in circles.

-P

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 14 Jul 2014 11:10:23 +1000

I don't really understand why the flow control mechanism is not sufficient
to implement priority?

My understanding of the use-case for priority is when a client received
many push promises and/or makes make parallel requests, then it can
stipulate which ones it wants to receive first.  Why can't it use flow
control windows to achieve this?

Is it the case that priority is needed for small resources that will not
need a window update to be sent?   But in that case, if you have 80
resources being pushed at you, 70 of them are probably in single frames so
by the time the client knows which ones it wants first they have probably
already been sent / queued etc.?

ie in all the scenarios that I can imagine, I can see flow control windows
being able to be used to control priority just as well as priority frames.

Perhaps somebody can writeup a few good examples of how they see priority
helping where flow control cannot?

thanks

On 14 July 2014 10:58, Tatsuhiro Tsujikawa <[email-masked]> wrote:

> >> > I've repeatedly seen arguments against adding anything optional to
> the spec. So why does PRIORITY get a pass? If it's truly optional, it could

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: David Krauss <[email-masked]>
Date: Mon, 14 Jul 2014 09:25:26 +0800

On 2014–07–14, at 9:10 AM, Greg Wilkins <[email-masked]> wrote:

> 
> I don't really understand why the flow control mechanism is not sufficient to implement priority?
> 
> My understanding of the use-case for priority is when a client received many push promises and/or makes make parallel requests, then it can stipulate which ones it wants to receive first.  Why can't it use flow control windows to achieve this?

Because, it’s a mess when the client treats the server as a slave. If the flow control window is throttled below the server’s minimum threshold, you get deadlock. There are no negative window updates, so throttling down requires draining the existing window, which is otherwise likely to be arbitrarily high.

TCP implementations jump through many hoops to work reliably. You might as well use multi-connection.

Prioritization is high-level. Flow control is low level. Throttling is a horrible violation of separation of concerns.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 14 Jul 2014 12:06:17 +0900

>
> ie in all the scenarios that I can imagine, I can see flow control
windows being able to be used to control priority just as well as priority
frames.
> thanks

Supporse client requested 2 resouces and they have priority weight 200 and
20.  With priority, server can send low prioritized resource with full
bandwidth if higher one is blocked (e.g., waiting file io or processing or
flow controll etc).
Without priority and small flow controll window is used, low prioritized
resource cannot use full bandwidth and suffers from performance
degradation. You may argue that client can increase window in this case,
because of latency it is too late to doing this and just make things messy.

Best regards,
Tatsuhiro Tsujikawa

connection handling.
>> >>
>> >> I’m in favor.
>> >>
>> >> Clients wishing to send PRIORITY should know whether the server is
just going to ignore it. It’s a good signal to use another prioritization
strategy, for example by reducing concurrency (start streams later).

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 09:33:54 +0000

> Removing PRIORITY is really bad idea.

Nobody is suggesting getting rid of PRIORITY.

I was merely suggesting that PRIORITY might be better served as a separate extension RFC, much like HPACK.

1) It makes the core h2 spec smaller and easier to grok (e.g. it wasn't obvious to me for a while that PRIORITY is completely optional)

2) *More importantly*, as PHK said (below) we can improve and version PRIORITY asynchronously with respect to the core h2 spec.

On Monday,14 July 2014 02:53, [email-masked] wrote:
> Making it an extension means we don't have to finish it at the
> same time as the base HTTP/2 spec, and that we can replace
> it with something better later on.

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Mon, 14 Jul 2014 10:56:40 +0000

> A multiplexed protocol doesn't work without prioritization.  Or rather, it ends up worse than what we currently have.

Why? You still get compression which implies less data on the wire and fewer connections meaning fewer resources (memory, entropy, IO) needed and a reduced impact of slow-start.

It might be suboptimal but I don't get "worse than what we currently have".

Richard

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Jul 2014 09:41:10 -0400

I've been doing interop with a spdy proxy that doesn't implement priority -
its way worse than h1. Click on a download and try and load a new page -
the page blocks on the download :)

These are just inherent properties of the protocol that can't be separated.
Frankly, alt-svc should be considered a basic property too because of the
load shedding problem associated with the h2 connection handling.

On Mon, Jul 14, 2014 at 6:56 AM, Richard Wheeldon (rwheeldo) <
[email-masked]> wrote:

>  > A multiplexed protocol doesn't work without prioritization.  Or rather,
> it ends up worse than what we currently have.
>
> Why? You still get compression which implies less data on the wire and
> fewer connections meaning fewer resources (memory, entropy, IO) needed and
> a reduced impact of slow-start.
>

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 13:44:50 +0000

On Monday,14 July 2014 15:41, [email-masked] wrote:
> I've been doing interop with a spdy proxy that doesn't implement priority - its
> way worse than h1. Click on a download and try and load a new page - the page
> blocks on the download :)
>

That begs the question, if it's so important, why isn't PRIORITY a *required* aspect of h2?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Jul 2014 09:44:58 -0400

> control windows to achieve this?
Tatsuhiro is right.

The most important reason is that the semantic you want is "among the N
things you have *available to send right now* these are the releative
importances and dependencies". And the receiver providing the priorities
cannot know the available set. It knows the outstanding set of requests but
some of them may be blocked (on disk i/o, on backend callouts, on auth,
etc..). Any scheduling algorithm benefits from having choices - if you
reduce the choices sometimes the answer is wasted idle bandwidth.

Right now with h1 browsers do silly tricks that more or less approximate
your suggestion (and indeed I'm contemplating some h1 changes that would
look even more like your suggestion). The most well known is that image
requests are basically held back while impt html/js/css is transferring.
This helps responsiveness because the image parallelism doesn't slowdown
the stuff that blocks rendering (that's why we do it), but it also results
in wasted idle bandwidth - only when the blocking resources have been
transferred do the image requests go out and that creates at least a 1 RTT
delay when compared to a prioritization scheme where the requests are all
sent immediately with the appropriate priorities.. (and its actually worse
than that if any of the html/js/css blocks). An h2 game where flow control
windows were turned up and down (h2 actually doesn't let you turn them down
- though of course it could be added) would be a similar mechanism.

Priority is a much better answer - send the requests as soon as you are
aware of them, but label the priority appropriately.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Mon, 14 Jul 2014 22:49:21 +0900

> extension RFC, much like HPACK.
Are you saying that ​we should separate PRIORITY as standalone document and
be referenced from h2 core spec?  Then it is not an *extension* RFC.  They
are in core spec but just in separate documents, so as the HPACK.

Best regards,
Tatsuhiro Tsujikawa

> 1) It makes the core h2 spec smaller and easier to grok (e.g. it wasn't
> obvious to me for a while that PRIORITY is completely optional)
>
> 2) *More importantly*, as PHK said (below) we can improve and version
> PRIORITY asynchronously with respect to the core h2 spec.
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Jul 2014 09:53:20 -0400

personally I wouldn't call it optional - it  is just unenforceable and has
no wire level requirements. So I guess its optional from an interop
perspective, but its impossible to do useful mux without it.

The definition of how the peer interprets weights is going to be a local
decision and as I mentioned in the next post you can't really know what is
instantaneously available to send from the other end of the pipe. Other
stuff flows into that - paging and buffering algorithms and what not. Some
priority is absolutely required to build a useful h2 implementation, but
there really are no MUSTs that can be put around it that mean anything.

we can certainly write some version of  "when choosing which stream to send
the peer MUST choose the highest priority stream that has data currently
available." But that doesn't actually do anything useful for compliance or
interop because "currently available" needs to be open ended and is
unknowable by the peer. Its a pointless MUST.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 14:52:33 +0000

In message <CAPyZ6=Jpe8q5Q0OSVy=mV=JyX4MP4EVWYVxat1OkgPjpuR=[email-masked]>, Tatsuhiro Tsujik
awa writes:

>Are you saying that we should separate PRIORITY as standalone document and

Purely from a textual point of view, that would be a good idea no matter
what status the priority stuff gets.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Jul 2014 09:47:49 -0700

>From a purely editorial perspective, I'd be opposed to this.  You guys
have created a lot of work for me already, and shuffling text between
documents doesn't help get us any closer to done.  And we're not done
until we have a prioritization story.

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 19:11:06 +0000

On 14 Jul 2014, at 18:47, "[email-masked]" <[email-masked]> wrote:
> have created a lot of work for me already

?

> , and shuffling text between
> documents doesn't help get us any closer to done.

I keep hearing this argument over and over. Is the goal just to finish, no matter what?

> And we're not done

I can't find that in the charter.

At the end of the day it was just a suggestion. I recall reading emails from several implementors which said they won't be implementing PRIORITY any time soon. It also takes up a big chunk of the spec and it's non-obvious if it's optional or not.  I was also surprised to read Patrick's claim that h2 won't work without PRIORITY because that claim isn't stated anywhere in the spec.

-Keith

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Jul 2014 12:14:37 -0700

On 14 July 2014 12:11,  <[email-masked]> wrote:
> that claim isn't stated anywhere in the spec.

We don't need to make those claims.  It's a specification.  It isn't
the role of the specification to justify itself, at least not on every
point.

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 19:44:40 +0000

On Jul 14, 2014, at 21:14, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

On 14 July 2014 12:11,  <[email-masked]<mailto:[email-masked]>> wrote:
that claim isn't stated anywhere in the spec.

Patrick said:

If you truly believe that, seems like you would want to explicitly state that in the spec. Otherwise you're setting up implementors for failure.

Or is it a secret?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Jul 2014 15:53:32 -0400

> I keep hearing this argument over and over. Is the goal just to finish, no

Of course not. But finishing is critically important.

An open standard is the output the process is judged by - and if it can't
produce that in a timely fashion then this forum has failed. If we don't
have the expectation that putting time and energy and implementations into
the process will yield a standard at least roughly according to a schedule
then there is no point in making that investment in the IETF.

We have spent almost 2 1/2 years vetting and tweaking a pre-existing
technology in an open forum. There aren't a lot of new angles to be looked
at anymore.

-P

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Jul 2014 16:04:00 -0400

On Mon, Jul 14, 2014 at 3:44 PM, <[email-masked]> wrote:

>
> Patrick said:
> A multiplexed protocol doesn't work without prioritization.  Or rather, it
> ends up worse than what we currently have.
>
>
Martin said that. I do concur.

> If you truly believe that, seems like you would want to explicitly state
> that in the spec. Otherwise you're setting up implementors for failure.
>
>
imo its a reasonable editorial suggestion... if you provide a pull request
the editor can decide. it would be fine by me either way. A specification
does not need to discuss every implication of the protocol as if it were a
text book but it obviously carries some non normative language to help the
reader put it all in context. I tend to prefer minimalism in the core
document, but that's not the in vogue style right now. The editor should
decide.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 20:30:07 +0000

In message <[email-masked]>, Patrick McManus 

>Of course not. But finishing is critically important.

Absolutely, but the quality of the result is far more important
than some arbitrary deadline.

>produce that in a timely fashion then this forum has failed. 

It has also fails if the produced standard is not good enough.

>technology in an open forum.

That's certainly one way to look at it.

My view is that the WG forged ahead on an urealistic schedule and
the wrong prototype, and is still not finished pull weeds and still
has basic issues to resolve.

Here is a cautionary tale of bad standardisation:

	http://csrc.nist.gov/groups/ST/crypto-review/documents/dualec_in_X982_and_sp800-90.pdf

Issues #2, #3 and #4 (last pages) are clearly relevant to this WG.

And if the editor is burned out, we should find another, rather than
publish whatever he burned out over.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 14 Jul 2014 15:09:34 -0700

On Mon, Jul 14, 2014 at 1:30 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <
> [email-masked]>,
> Patrick McManus
> writes:
>
> >> I keep hearing this argument over and over. Is the goal just to finish,
> no
> >> matter what?
> >

The most important part is deployment.
This is true of transports and application-layer stuff.
.. and we know it works when folks implement things properly, because we
have experience in production with real, real-world use.
The risk of getting it terribly wrong is low given this implementation
experience.

> It has also fails if the produced standard is not good enough.

Yes. I'll point out that failure method B does not imply failure method A,
or vice versa, however.

> has basic issues to resolve.

This one makes me laugh: What was the "right" prototype?

> publish whatever he burned out over.

Not touching this with 10 ft cattle prod.
-=R

---

From: Jason Greene <[email-masked]>
Date: Mon, 14 Jul 2014 18:00:17 -0500

On Jul 14, 2014, at 5:09 PM, Roberto Peon <[email-masked]> wrote:

> 
> 
> 
> On Mon, Jul 14, 2014 at 1:30 PM, Poul-Henning Kamp <[email-masked]> wrote:
> .. and we know it works when folks implement things properly, because we have experience in production with real, real-world use.
> The risk of getting it terribly wrong is low given this implementation experience.

What about the stream dependencies though? I assume you mean the experience is the simpler SPDY priority? 

The spec would be a hell of a lot simpler without this dep complexity, which is what I think scares people away (well that and the scary rfc comment). 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Roberto Peon <[email-masked]>
Date: Mon, 14 Jul 2014 16:04:18 -0700

On Mon, Jul 14, 2014 at 4:00 PM, Jason Greene <[email-masked]>
wrote:

> > >> I keep hearing this argument over and over. Is the goal just to
> finish, no
> > >> matter what?
> > >
> The spec would be a hell of a lot simpler without this dep complexity,
> which is what I think scares people away (well that and the scary rfc
> comment).
>
>
We know that getting priority right is necessary to experiencing the
potential benefit of multiplexing.
We know that the simply priority scheme from SPDY kinda worked, but was
failling for a number of usecases.
Given that the old priority system expresses a subset of what the new one
allows, it is unlikely we'd be making anything worse, though there is a
complexity price to pay.
-=R

---

From: Jason Greene <[email-masked]>
Date: Mon, 14 Jul 2014 18:19:36 -0500

On Jul 14, 2014, at 6:04 PM, Roberto Peon <[email-masked]> wrote:

> 
> 
> 
> On Mon, Jul 14, 2014 at 4:00 PM, Jason Greene <[email-masked]> wrote:
> 
> We know that getting priority right is necessary to experiencing the potential benefit of multiplexing.
> We know that the simply priority scheme from SPDY kinda worked, but was failling for a number of usecases.
> Given that the old priority system expresses a subset of what the new one allows, it is unlikely we'd be making anything worse, though there is a complexity price to pay.
> -=R
>  

OK, thats good to know.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 15 Jul 2014 09:41:13 +1000

For my part, I think the discussion here has well motivated the need for
priority (let's put it in the FAQ!)

> technology in an open forum. There aren't a lot of new angles to be looked

Still, you have to expect the more eyeballs on the protocol as it
approaches LC.     The fact that some issues were discuss and decided 2 1/2
years ago does not mean that they will prove to be acceptable to a wider
audience.  Mistakes do get made and good decisions sometime don't look so
great with some perspective.

If new input really isn't welcome, then the process should lock in the
experts at the start of the process (kind of like the JCP does) and let
them run to completion...... but my general experience is that I've been
much happier implementing RFCs than I have implementing JSRs.   There is
value in the IETF process... no mater how ugly it gets.

While it may not sound like it often, I for one do appreciate the efforts
of those that have been here for the the full 2 1/2 years and definitely
appreciate the patience displayed when issues previously discussed are re
explained and re-evaluated.

thanks!

---

From: Jason Greene <[email-masked]>
Date: Mon, 14 Jul 2014 20:00:18 -0500

On Jul 14, 2014, at 6:41 PM, Greg Wilkins <[email-masked]> wrote:

> 
> For my part, I think the discussion here has well motivated the need for priority (let's put it in the FAQ!)
> 
> We have spent almost 2 1/2 years vetting and tweaking a pre-existing technology in an open forum. There aren't a lot of new angles to be looked at anymore.
> 
> Still, you have to expect the more eyeballs on the protocol as it approaches LC.     The fact that some issues were discuss and decided 2 1/2 years ago does not mean that they will prove to be acceptable to a wider audience.  Mistakes do get made and good decisions sometime don't look so great with some perspective.
> 
> If new input really isn't welcome, then the process should lock in the experts at the start of the process (kind of like the JCP does) and let them run to completion...... but my general experience is that I've been much happier implementing RFCs than I have implementing JSRs.   There is value in the IETF process... no mater how ugly it gets.
> 
> While it may not sound like it often, I for one do appreciate the efforts of those that have been here for the the full 2 1/2 years and definitely appreciate the patience displayed when issues previously discussed are re explained and re-evaluated.  

I’ll second that. I am certainly trying to limit this to critical issues that effect my implementation.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jul 2014 14:19:53 +1000

This thread seems to have resolved itself, so I'll just add that in the past we've split things off into extensions when they're both optional *and* doing so is relatively uncontroversial. This clearly isn't the case here.

Generally, I consider issues like this to be editorial -- i.e., it's about how the spec is structured, and therefore under the purview of the editor; the protocol itself doesn't care which document what is defined in. As such, editorial feedback is always appreciated by Martin, but we shouldn't get too bogged down on the list about this sort of thing -- never mind trying to justify one's position on this sort of thing based upon charter-lawyering.

Regards,

--
Mark Nottingham   https://www.mnot.net/