W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: http/2 prioritization/fairness bug with proxies

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Tue, 5 Feb 2013 10:47:19 +0900
Message-ID: <CAA4WUYiyu+JvFuKooqa4xVdCJP=Mngu9dgHjhH99_SEac1kCZQ@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
I'm sorry if I am unclear in any way. Please continue to
challenge/question my comments/assertions so I can clarify my position
as appropriate.

Just to be clear here, I stand by that it's a protocol bug currently.
I agree with adding more hooks to convey advisory priority semantics.
That said, "advisory" is open to interpretation. I agree that the
sender should ultimately be in control of how it orders responses, and
indeed there are of course many situations where it's best for the
sender to ignore the advisory priority. Yet, if the advisory priority
semantics are generally not respected, then clients will not be able
to rely on them, and will be forced to implement prioritization at a
higher layer, which suffers from the link underutilization vs
contention tradeoff I highlighted earlier.

I appreciate the concern that we're adding complexity by introducing
new semantics. I am arguing that because the existing mechanisms for
addressing starvation are suboptimal, we should treat this as a
protocol bug and thus change the protocol in such a way as to fix this
problem. My suggestion for doing so was adding new priority "grouping"
semantics. I am hopeful that these new semantics will not introduce an
inordinate amount of specification, as the primary idea is that the
current SPDY priority levels would apply within a "group". I think we
can come up with a way to define a group that will be relatively easy
to spec.

SPDY/4 introduces other prioritization semantics beyond just grouping,
but I wanted to focus on this one first, as I believe this is a bug
that we *need* to fix. The other SPDY/4 priority changes are of a
performance optimization nature, and I believe they will need to be
justified by data. I have no plans to raise them up in this group
until we have said data.

On Tue, Feb 5, 2013 at 5:34 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <42A54D15-0AA3-4172-94F7-E94C86E84D7F@niven-jenkins.co.uk>, Ben Nive
> n-Jenkins writes:
>>So the idea is the protocol contains enough 'hooks' to sufficiently
>>express the different priorities between & within groups that folks
>>would like to express but isn't prescriptive about how anyone uses or
>>implements different prioritisation, scheduling, etc schemes.
> That was clearly not how the original poster presented it:
>         "I consider all those options as suboptimal, and thus
>         consider this issue to be a protocol bug. Our SPDY/4
>         prioritization proposal addresses this by [...]"
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 5 February 2013 01:47:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC