Re: http/2 prioritization/fairness bug with proxies

That's not at all what I had in mind, just a general re-iteration of
the basic principles:

Primarily:  Send bits based on availability and relative priorities.
Secondarily:  Advertise flow control window availability based on when
those bits are consumed (i.e. sent onwards).

On 11 February 2013 14:57, Roberto Peon <grmocg@gmail.com> wrote:
> I think that the overall complexity spend is lower when we put the
> complexity into prioritization mechanisms instead of stuffing heuristics
> into the flow control... (because that is just ewww and ouch in so many
> ways..)
>
> -=R
>
>
> On Mon, Feb 11, 2013 at 2:53 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> I'm thinking a simple mechanism.  The proxy can feed requests back to
>> clients based on its own prioritization and use flow control windows
>> on the back-end connections to ensure that it doesn't have to buffer
>> infinitely.  Basically, the same sorts of logic that would be needed
>> by a proxy that serves multiple clients.
>>
>> Yes, this is sub-optimal because it leads to either poor bandwidth
>> utilization, lots of buffering, or worse.
>>
>> Sure, it's very easy to get this wrong.  I don't believe it
>> unreasonable to consider this sort of thing to be marked "hard hat
>> area".  In both directions.
>>
>> On 11 February 2013 14:46, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>> > Theoretically possible is one thing. But the moment we get into the game
>> > of
>> > trying to carve up portions of BDP via per-stream flow control windows
>> > for
>> > prioritization purposes in normal operation (as opposed to just trying
>> > to
>> > make reasonable progress under excessive load), I think we're in
>> > trouble,
>> > and likely to get into performance issues due to poor implementations.
>> > As
>> > I've stated before, I hope most implementations (and believe we should
>> > add
>> > recommendations for this behavior) only use flow control (if they use it
>> > at
>> > all, which hopefully they don't because it's hard) for maintaining
>> > reasonable buffer sizes.
>> >
>> >
>> > On Mon, Feb 11, 2013 at 2:39 PM, Martin Thomson
>> > <martin.thomson@gmail.com>
>> > wrote:
>> >>
>> >> Keep in mind that it is always possible for the intermediary to apply
>> >> flow control to the infinite length stream so that, regardless of
>> >> priority, it doesn't consume more than its fair share.
>> >>
>> >> On 10 February 2013 14:40, William Chan (陈智昌) <willchan@chromium.org>
>> >> wrote:
>> >> > First, I totally agree SPDY/4 prioritization changes are far more
>> >> > reaching.
>> >> > Let's not talk about them yet. I share your complexity concern and
>> >> > agree
>> >> > we
>> >> > need data before proceeding with many of those features, and I plan
>> >> > on
>> >> > getting data.
>> >> >
>> >> > As far as grouping, I think it's definitely a bug for the case where
>> >> > you
>> >> > have a forward proxy with users sharing the same HTTP/2.0 connection
>> >> > to
>> >> > an
>> >> > origin server. You can have many high priority short-lived streams
>> >> > which
>> >> > can
>> >> > starve out others, unless we implement the vague notion of "don't
>> >> > starve
>> >> > out
>> >> > streams", which is difficult when it might be a sustained rate of
>> >> > high
>> >> > priority short-lived streams. It's easier in your latter case of
>> >> > infinite,
>> >> > high-priority streams.
>> >> >
>> >> > You're right that the high priority, infinite stream can starve
>> >> > streams
>> >> > within the same group. I don't think this means that grouping is not
>> >> > required, but that grouping is potentially insufficient. For
>> >> > intragroup
>> >> > starvation, I think it's debatable about whether the server should be
>> >> > smart
>> >> > and not allow streams to _completely_ starve other streams within a
>> >> > group,
>> >> > or that clients should have a reprioritization facility. I think this
>> >> > is
>> >> > a
>> >> > discussion worth having, but I'd personally classify it as separate
>> >> > from
>> >> > whether or not the grouping feature is necessary.
>> >> >
>> >> > On Sun, Feb 10, 2013 at 2:06 PM, Mike Belshe <mike@belshe.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 4, 2013 at 5:47 PM, William Chan (陈智昌)
>> >> >> <willchan@chromium.org>
>> >> >> 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.
>> >> >>
>> >> >>
>> >> >> +0.5.  :-)
>> >> >>
>> >> >> Mark - I think we could open a issue ticket with the current
>> >> >> HTTP/2.0
>> >> >> draft that this is a bug which will present itself for servers that
>> >> >> implement naively.  This isn't strictly a "bug", since the spec says
>> >> >> the
>> >> >> server can do whatever it wants with priorities, but this is subtle
>> >> >> enough
>> >> >> (surfacing primarily in http/2 -> http/2 proxy situations), that
>> >> >> many
>> >> >> server
>> >> >> implementors won't think of it unless we mention it in the spec.
>> >> >>
>> >> >> The bare minimum would be to simply document it and tell servers not
>> >> >> to
>> >> >> starve out streams.  However, this is probably a wimpy approach and
>> >> >> I
>> >> >> think
>> >> >> we can do better.
>> >> >>
>> >> >> The SPDY/4 prioritization changes are far more reaching than just
>> >> >> fixing
>> >> >> this bug.  While I like grouping as a feature, I don't believe it
>> >> >> actually
>> >> >> fixes this bug:  a browser could open a high priority, infinite
>> >> >> stream,
>> >> >> which is competing across a shared proxy backend with other streams;
>> >> >> unless
>> >> >> the user manually switches tabs (or does something to force changed
>> >> >> groups),
>> >> >> the starvation can still occur.
>> >> >>
>> >> >> Mike
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> 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 Monday, 11 February 2013 23:22:10 UTC