From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <narseo@icsi.berkeley.edu>
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19])
	by huchra.bufferbloat.net (Postfix) with ESMTP id 4DF2921F35A
	for <bloat@lists.bufferbloat.net>; Thu, 12 Mar 2015 11:18:10 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B2A9E2C4051
	for <bloat@lists.bufferbloat.net>; Thu, 12 Mar 2015 11:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1])
	by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new,
	port 10024)
	with LMTP id MzF5wjYlpmQd for <bloat@lists.bufferbloat.net>;
	Thu, 12 Mar 2015 11:18:10 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com
	[209.85.216.171]) (Authenticated sender: narseo)
	by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 406632C4053
	for <bloat@lists.bufferbloat.net>; Thu, 12 Mar 2015 11:18:10 -0700 (PDT)
Received: by qcwb13 with SMTP id b13so20700449qcw.9
	for <bloat@lists.bufferbloat.net>; Thu, 12 Mar 2015 11:18:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.31.94 with SMTP id f91mr36096470qkf.94.1426184289371;
	Thu, 12 Mar 2015 11:18:09 -0700 (PDT)
Received: by 10.96.136.39 with HTTP; Thu, 12 Mar 2015 11:18:09 -0700 (PDT)
In-Reply-To: <CAJq5cE28yrYQEt8UMDZ6xTGOXbzXKY-a9BfQs3TOFPQ2KtyVgw@mail.gmail.com>
References: <CANOtCLVp_A3hXd_vto2_SO=trH8-bQnAJV3iWswHM4xUmr5XSA@mail.gmail.com>
	<CAJq5cE28yrYQEt8UMDZ6xTGOXbzXKY-a9BfQs3TOFPQ2KtyVgw@mail.gmail.com>
Date: Thu, 12 Mar 2015 11:18:09 -0700
Message-ID: <CAJmR=Qm6xdX2gGq+cGM2awyDYJK+5t4-HpvRVHZ-Ng9AbNi64w@mail.gmail.com>
From: Narseo Vallina Rodriguez <narseo@icsi.berkeley.edu>
To: Jonathan Morton <chromatix99@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Jordan Peacock <hewhocutsdown@gmail.com>, Kartik Agaram <ak@akkartik.com>,
	bloat <bloat@lists.bufferbloat.net>
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 <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 18:18:39 -0000

Hi Jonathan

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

The way you're describing this specific part, sounds more to me like a
control-plane latency issue (i.e., the time for the RNC to allocate a
radio channel to the client by promoting it from IDLE/FACH to DCH)
rather than a buffer size related issue (which is actually introduced
both on the handset and the RNC/eNB to deal with the C-Plane latency)

https://www.qualcomm.com/media/documents/files/qualcomm-research-latency-in-hspa-data-networks.pdf