Re: http/2 prioritization/fairness bug with proxies
Martin Thomson <martin.thomson@gmail.com> Mon, 11 February 2013 22:54 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 9C9F821F8A94 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 14:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.172
X-Spam-Level:
X-Spam-Status: No, score=-8.172 tagged_above=-999 required=5 tests=[AWL=2.127, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 X7y36r+5Jw1l for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 14:54:12 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0B21F8A66 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Feb 2013 14:54:12 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U52Fl-0008Ni-35 for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Feb 2013 22:53:37 +0000
Resent-Date: Mon, 11 Feb 2013 22:53:37 +0000
Resent-Message-Id: <E1U52Fl-0008Ni-35@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U52Fb-0008M7-V3 for ietf-http-wg@listhub.w3.org; Mon, 11 Feb 2013 22:53:27 +0000
Received: from mail-wg0-f53.google.com ([74.125.82.53]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U52Fa-00074i-Jc for ietf-http-wg@w3.org; Mon, 11 Feb 2013 22:53:27 +0000
Received: by mail-wg0-f53.google.com with SMTP id fn15so5303681wgb.32 for <ietf-http-wg@w3.org>; Mon, 11 Feb 2013 14:53:00 -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:content-transfer-encoding; bh=vJkltqQE/CnA6WRatNsyaaAZxbQA9QYQzVy8yECV2jQ=; b=IbL+xzGq8+8W9V0y7nla+suUHLHN/UzuVyeYdwfSGwy60ZIO2lso7+4ETFoofIgCY5 JnQc+XzVYQMSXQgB++gDLZNapepP7gAWSuc8otSnoplXpcIdcRxPf5rOeVWih/fLYXNT HGpoazIKv922WD2vTXzMDsnj8IZ/CE4E6EnsWFI1tyLNYgL/TJxkMurvjUU6j/hGk0Lp iCmdBdKRY20sUeIE78/2jqawbR086Oh1yt3Y1QBw4aGJN00LqiuEg8DeGG1Bn1CYZ3Cc /ZAUmQjQUkauQ11zgP+S/KhtNp0IqSKeQpTA1CnL+Mk0fb86/O2QS345nA6u5cu4awjQ vYdw==
MIME-Version: 1.0
X-Received: by 10.180.104.196 with SMTP id gg4mr19060411wib.16.1360623180190; Mon, 11 Feb 2013 14:53:00 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Mon, 11 Feb 2013 14:53:00 -0800 (PST)
In-Reply-To: <CAA4WUYg+evqEMdiYSv+EZ7668eCq_dwqKiYmA4Lq-xZkoD_9Fw@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>
Date: Mon, 11 Feb 2013 14:53:00 -0800
Message-ID: <CABkgnnVPYYx9NUXmO=1_1J0Vgk4N51DKzVWiWxhYhvEyZeLKnQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: Mike Belshe <mike@belshe.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=74.125.82.53; envelope-from=martin.thomson@gmail.com; helo=mail-wg0-f53.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.637, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U52Fa-00074i-Jc 962f5ad8d70090ac67031aeffa65ba1f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: http/2 prioritization/fairness bug with proxies
Archived-At: <http://www.w3.org/mid/CABkgnnVPYYx9NUXmO=1_1J0Vgk4N51DKzVWiWxhYhvEyZeLKnQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16571
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>
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. >> >>> >> >> >> > > >
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- http/2 prioritization/fairness bug with proxies William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Yoav Nir
- Re: http/2 prioritization/fairness bug with proxi… Mark Nottingham
- Re: http/2 prioritization/fairness bug with proxi… Poul-Henning Kamp
- Re: http/2 prioritization/fairness bug with proxi… Ilya Grigorik
- Re: http/2 prioritization/fairness bug with proxi… Amos Jeffries
- Re: http/2 prioritization/fairness bug with proxi… Mark Nottingham
- Re: http/2 prioritization/fairness bug with proxi… Amos Jeffries
- Re: http/2 prioritization/fairness bug with proxi… Albert Lunde
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… James M Snell
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Poul-Henning Kamp
- Re: http/2 prioritization/fairness bug with proxi… Ben Niven-Jenkins
- Re: http/2 prioritization/fairness bug with proxi… Poul-Henning Kamp
- Re: http/2 prioritization/fairness bug with proxi… Patrick McManus
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Ashok Kumar
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Mike Belshe
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Martin Thomson
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Martin Thomson
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Martin Thomson
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Martin Thomson
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… Yoav Nir
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Amos Jeffries
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… Roberto Peon
- Re: http/2 prioritization/fairness bug with proxi… Amos Jeffries
- Re: http/2 prioritization/fairness bug with proxi… Nico Williams
- Re: http/2 prioritization/fairness bug with proxi… William Chan (陈智昌)