Re: http/2 prioritization/fairness bug with proxies

Roberto Peon <grmocg@gmail.com> Mon, 11 February 2013 23:28 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52621F87FE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 15:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.53
X-Spam-Level:
X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlHcfySosXRr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 15:28:29 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DDB4921F871C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Feb 2013 15:28:28 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U52n2-0007r5-Oy for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Feb 2013 23:28:00 +0000
Resent-Date: Mon, 11 Feb 2013 23:28:00 +0000
Resent-Message-Id: <E1U52n2-0007r5-Oy@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U52mu-0007qL-8d for ietf-http-wg@listhub.w3.org; Mon, 11 Feb 2013 23:27:52 +0000
Received: from mail-oa0-f41.google.com ([209.85.219.41]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U52mn-0003VV-HM for ietf-http-wg@w3.org; Mon, 11 Feb 2013 23:27:52 +0000
Received: by mail-oa0-f41.google.com with SMTP id i10so6833923oag.28 for <ietf-http-wg@w3.org>; Mon, 11 Feb 2013 15:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pVmAod4mWl42d+6PO5tUmlgRS4FygR7+N2j/+Wa1wYc=; b=whCNCTAhT2pvG8Znqt+t/L4OWqj9rLBL9ZHjYWrtYgJmowo08XOVuFqyVP3Sp1MU+L Gd8rHeHavInX+SLhL0Xesya76vVZ7LGwTxv2abHp4jnTp868ETxT6PjA1pLjXxwqwNjU ig9LZHP8a6v/ZEiM9QXzFs71b2Q0V2ieyu9eZktIpJpqn3E6Cj47BwN6W5x/HyflbxBw rRYXq8X3+NyzkmdlBBjR7ldm6BowIGV6dRq3lmB99ufYKJYgC8MiXNvI5JNAtw7aSSKU lBSBmOeCFUq+eH3CZG3IpVgBQvUMBPqX+gHtM0X69OHFiHpExt/uryX6aDLzf3vi3SVO J8Fw==
MIME-Version: 1.0
X-Received: by 10.60.27.199 with SMTP id v7mr11847690oeg.23.1360625239242; Mon, 11 Feb 2013 15:27:19 -0800 (PST)
Received: by 10.76.167.193 with HTTP; Mon, 11 Feb 2013 15:27:19 -0800 (PST)
In-Reply-To: <CABkgnnUvNfFsnB8q-1mrV1uScuiH-fG3NKgujLWmH1a0ytbMjg@mail.gmail.com>
References: <CAA4WUYjiBZpShKKFfHQnixc94aOLrck0oR4ykARB=hF5h8nkfA@mail.gmail.com> <3430.1359961022@critter.freebsd.dk> <510F72CE.8030003@treenet.co.nz> <CAA4WUYiBJrLjM0-vurFOuJfUaabXtK=W8N5z28yshSfrvD9crg@mail.gmail.com> <1516.1360002578@critter.freebsd.dk> <42A54D15-0AA3-4172-94F7-E94C86E84D7F@niven-jenkins.co.uk> <2346.1360010079@critter.freebsd.dk> <CAA4WUYiyu+JvFuKooqa4xVdCJP=Mngu9dgHjhH99_SEac1kCZQ@mail.gmail.com> <CABaLYCtX04se2BJ0c1yCYkwH2xvkcETdu7Pe+B8fy=DJrouo6Q@mail.gmail.com> <CAA4WUYitNR0js+5m5RHfLp-7=k-mfTUKDcayW-uzJwTgOgMyYQ@mail.gmail.com> <CABkgnnUYKDe4rZ0ZpqASkwDF2Foa_ni1rEFJH1P03k1Bv_NCog@mail.gmail.com> <CAA4WUYg+evqEMdiYSv+EZ7668eCq_dwqKiYmA4Lq-xZkoD_9Fw@mail.gmail.com> <CABkgnnVPYYx9NUXmO=1_1J0Vgk4N51DKzVWiWxhYhvEyZeLKnQ@mail.gmail.com> <CAP+FsNfKwuy4iy4JnvVS5pQrzDnVdt9SrrfDvGM68CxL-_t48Q@mail.gmail.com> <CABkgnnUvNfFsnB8q-1mrV1uScuiH-fG3NKgujLWmH1a0ytbMjg@mail.gmail.com>
Date: Mon, 11 Feb 2013 15:27:19 -0800
Message-ID: <CAP+FsNdGt12dOnP-YRm6s2Zcn56K1RxOz8kqEvGQ5=yE6E=_DA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="e89a8fb200780eb7e504d57b40d2"
Received-SPF: pass client-ip=209.85.219.41; envelope-from=grmocg@gmail.com; helo=mail-oa0-f41.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.640, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U52mn-0003VV-HM 395795124c51b4db451903520a2dcad0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: http/2 prioritization/fairness bug with proxies
Archived-At: <http://www.w3.org/mid/CAP+FsNdGt12dOnP-YRm6s2Zcn56K1RxOz8kqEvGQ5=yE6E=_DA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16576
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

If that is what you're saying, then I definitely misunderstood. I thought
you were advocating using flow control to reduce the effective priority of
a long-running item?
-=R


On Mon, Feb 11, 2013 at 3:21 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> 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.
> >> >> >>>
> >> >> >>
> >> >> >
> >> >
> >> >
> >>
> >
>