From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (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 E51D321F35A for ; Thu, 12 Mar 2015 11:39:41 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id id10so6083323vcb.8 for ; Thu, 12 Mar 2015 11:39:40 -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=KVsLTERjr/f+Haow2Ro/hftNjVIw0TdWMIo1RVLe+bQ=; b=APXYfcsKeAizP4z11VaI5hXx/U2fBW12y3gVmGlklyAEU2HsKuuPIUIoH+0IzsK/KR znlKTCxhkUCsW3nDgYEHN2AcMwbIBT+kDWANxgZWX8iCOECqaPMEZfUglPQ5hzpVkTSV iUfbiqZLaIKI1nuH8JFORp1wvqQ9ulKKaWaRLObIMwoDUorYJvVcbGFDxKVB4iR1Nfnv Z6x/GohUUCle8jsXFMoVqBbezZu5GVsVIUESwDTqfbAuQ/wofWEDV0wxNJ7+fy3aH+RD RNL4vMRI+UC2U6zgo8Ny8Tmz0gq5cVxpj4LaioOVGWEbcA9jIgbgdrej+ktWEpXr9k08 bX5Q== MIME-Version: 1.0 X-Received: by 10.52.3.74 with SMTP id a10mr1135542vda.95.1426185580535; Thu, 12 Mar 2015 11:39:40 -0700 (PDT) Received: by 10.52.92.65 with HTTP; Thu, 12 Mar 2015 11:39:40 -0700 (PDT) Received: by 10.52.92.65 with HTTP; Thu, 12 Mar 2015 11:39:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 20:39:40 +0200 Message-ID: From: Jonathan Morton To: Narseo Vallina Rodriguez Content-Type: multipart/alternative; boundary=20cf3033477fe9675e05111bb452 Cc: Kartik Agaram , 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 18:40:10 -0000 --20cf3033477fe9675e05111bb452 Content-Type: text/plain; charset=UTF-8 On 12 Mar 2015 20:18, "Narseo Vallina Rodriguez" wrote: > > 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 No, that's backwards. The first connection is the most reliable, because the link isn't loaded yet, and trying to make later connections times out because the buffers are full from the first ones, still in progress. If C-plane latency was the problem, the symptoms would be reversed - unless the system is inexplicably reverting to the idle state between packets in a continuous stream, and I refuse to believe it's that dumb without firm evidence. Unloaded latency on this link is on the order of 100ms. - Jonathan Morton --20cf3033477fe9675e05111bb452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 12 Mar 2015 20:18, "Narseo Vallina Rodriguez" &= lt;narseo@icsi.berkeley.edu= > wrote:
>
> Hi Jonathan
>
> > Status quo is that loading a web page with many resources on it i= s
> > unreliable. Early connections succeed and become established, the= congestion
> > window opens, the buffer in the 3G tower begins to fill up, induc= ing 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 brok= en.
> >
>
> The way you're describing this specific part, sounds more to me li= ke a
> control-plane latency issue (i.e., the time for the RNC to allocate a<= br> > radio channel to the client by promoting it from IDLE/FACH to DCH)
> rather than a buffer size related issue (which is actually introduced<= br> > both on the handset and the RNC/eNB to deal with the C-Plane latency)<= br> >
> https://www.qualcomm.com/media/doc= uments/files/qualcomm-research-latency-in-hspa-data-networks.pdf

No, that's backwards. The first connection is the most r= eliable, because the link isn't loaded yet, and trying to make later co= nnections times out because the buffers are full from the first ones, still= in progress. If C-plane latency was the problem, the symptoms would be rev= ersed - unless the system is inexplicably reverting to the idle state betwe= en packets in a continuous stream, and I refuse to believe it's that du= mb without firm evidence.

Unloaded latency on this link is on the order of 100ms.

- Jonathan Morton

--20cf3033477fe9675e05111bb452--