From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 55A9921F2F4 for ; Thu, 12 Mar 2015 08:02:42 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so5622077vcb.4 for ; Thu, 12 Mar 2015 08:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3qJiSYXi7ASlPMvWCiARJVaGJAqcmVzm2Vk/giQfbQ=; b=fI/RDHZ+O7c3QqDbuj7Icj7xejCyeK5km+AO5Dc9CqRN6jGC+Ud24vq+yc431MdfAH uc8ma0Bjvht1Op60SgRgCReCh++A0ypRpH0o09/ISs25r/6zuzWmyaDX27qxKgyev5La QmAlZdgxalhkqoN+h3nEzbQpItXwPnlVi+LQQrOq+EJzC19078kUFwv7pu4OOFkOmbq3 k8qAOgqaVshkrE/rlO2Xtfez5jimHWc5t0LEBnZ8mDwxsJTLcjJeNuhfUQXXSs3C4ljN 6Iw75cbENi9GP6HzX3ithx8sziYx6nDinEK1e22Sqc7gFXAwf2/gA/0U5zambT1iem3X fQ9w== MIME-Version: 1.0 X-Received: by 10.52.27.211 with SMTP id v19mr17705139vdg.35.1426172561715; Thu, 12 Mar 2015 08:02:41 -0700 (PDT) Received: by 10.52.92.65 with HTTP; Thu, 12 Mar 2015 08:02:41 -0700 (PDT) Received: by 10.52.92.65 with HTTP; Thu, 12 Mar 2015 08:02:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 17:02:41 +0200 Message-ID: From: Jonathan Morton To: Kartik Agaram Content-Type: multipart/alternative; boundary=20cf307d06d2edf638051118acf1 Cc: Jordan Peacock , bloat Subject: Re: [Bloat] http/2 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:03:11 -0000 --20cf307d06d2edf638051118acf1 Content-Type: text/plain; charset=UTF-8 I think you may be conflating several different buffers which exist in different places and are controlled by different means. I'll try to illustrate this using a single scenario with which I'm personally familiar: a half megabit 3G connection without AQM. Status quo is that loading a web page with many resources on it is unreliable. Early connections succeed and become established, the congestion window opens, the buffer in the 3G tower begins to fill up, inducing several seconds of latency, and subsequent DNS lookups and TCP handshakes tend to time out. End result: often, half the images on the page are broken. Status quo is also that a single big, continuous download (such as a software update) is capable of inducing 45 seconds of latency on the same connection, making it virtually impossible to do anything else with it concurrently. This corresponds to several megabytes of dumb buffering in the tower AND several megabytes of TCP receive window AND several megabytes of TCP congestion window. Lose any one of those three things and the induced latency disappears. But it's there, with a single connection. As far as bufferbloat is concerned, HTTP 2 just converts the first situation into the second one. If images and other resources are loaded from the same server as the base page, as they should be, then they'll load more reliably. But any resource loaded externally (even just sharded off) will become less reliable (if anything) in the presence of bufferbloat, because a separate connection still has to be made per host server. If the queue in the tower was less dumb, then TCP would be given congestion signals when it began to fill up. In that situation, HTTP 2 helps because there are fewer connections that need to receive that signal to be effective. - Jonathan Morton --20cf307d06d2edf638051118acf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think you may be conflating several different buffers whic= h exist in different places and are controlled by different means.=C2=A0 I&= #39;ll try to illustrate this using a single scenario with which I'm pe= rsonally familiar: a half megabit 3G connection without AQM.

Status quo is that loading a web page with many resources on= it is unreliable. Early connections succeed and become established, the co= ngestion window opens, the buffer in the 3G tower begins to fill up, induci= ng several seconds of latency, and subsequent DNS lookups and TCP handshake= s tend to time out. End result: often, half the images on the page are brok= en.

Status quo is also that a single big, continuous download (s= uch as a software update) is capable of inducing 45 seconds of latency on t= he same connection, making it virtually impossible to do anything else with= it concurrently. This corresponds to several megabytes of dumb buffering i= n the tower AND several megabytes of TCP receive window AND several megabyt= es of TCP congestion window. Lose any one of those three things and the ind= uced latency disappears. But it's there, with a single connection.

As far as bufferbloat is concerned, HTTP 2 just converts the= first situation into the second one. If images and other resources are loa= ded from the same server as the base page, as they should be, then they'= ;ll load more reliably. But any resource loaded externally (even just shard= ed off) will become less reliable (if anything) in the presence of bufferbl= oat, because a separate connection still has to be made per host server.

If the queue in the tower was less dumb, then TCP would be g= iven congestion signals when it began to fill up. In that situation, HTTP 2= helps because there are fewer connections that need to receive that signal= to be effective.

- Jonathan Morton

--20cf307d06d2edf638051118acf1--