Re: http/2 prioritization/fairness bug with proxies

[Roberto Peon <[e-mail]>]

It should always keep the pipe full, but it should be using small enough
frames that it can respond with alacrity to a higher priority resource.
So, in generally, the algorithm should be something like:

WriteToAStream():
  for priority-bucket in active-priority-list:
    for stream in priority-bucket:
      if is_readable(stream):
        outbound.WriteData(stream, 2**14)
        return

other variations are possible, but that is the basic idea.


On Thu, Feb 7, 2013 at 9:50 PM, Ashok Kumar <[e-mail]> wrote:

> On Feb 4, 2013 8:05 AM, "Amos Jeffries" <squid3 <[e-mail]>@<[e-mail]>
> treenet.co.nz <[e-mail]>> wrote:
> > Priority 1 - user actioned fetch - requires fast answer
> > Priority 2 - background/automated fetch in user-visible window -
> requires fast answer but treat as bulk traffic.
> > Priority 3 - automated software fetch - treat as low-speed traffic.
> > Priority 4 - idle software probe - may drop if necessary.
>
> I still feel fixed priorities have better use, from a server point of
> view. The description may need to be tweaked a bit from the user-agent's
> needs perspective. A number will always have different meaning from
> different clients and server is not best place to guess who is more
> important.
>
> One tangential question, please spare me if this is not the right place.
> How is priority supposed to work from a server's perspective. Let's say
> Apache has a MaxClient of 1000. Will it stop accepting normal requests
> after it has used up 80% quota and will wait for higher priority requests?
> May be a trivial implementation detail but this has been bothering me for
> sometime and I thought this might help in deciding how priorities should be
> sent/interpreted.
>
>
>
>
> On Tue, Feb 5, 2013 at 7:17 AM, William Chan (陈智昌) <[e-mail]>wrote:
>
>> 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 <[e-mail]>
>> wrote:
>> > Content-Type: text/plain; charset=ISO-8859-1
>> > --------
>> > In message <[e-mail]>,
>> 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
>> > [e-mail]         | TCP/IP since RFC 956
>> > FreeBSD committer       | BSD since 4.3-tahoe
>> > Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>>
>
>
> --
> .- ... .... --- -.-
>