From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by huchra.bufferbloat.net (Postfix) with ESMTP id 9CC12200111 for ; Thu, 12 Mar 2015 11:56:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E792A2C4054 for ; Thu, 12 Mar 2015 11:56:21 -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 xQmp8Ln3E9MT for ; Thu, 12 Mar 2015 11:56:20 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 420C32C4053 for ; Thu, 12 Mar 2015 11:56:20 -0700 (PDT) Received: by qcrw7 with SMTP id w7so20945038qcr.8 for ; Thu, 12 Mar 2015 11:56:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.86.199 with SMTP id p65mr55103477qgd.49.1426186579273; Thu, 12 Mar 2015 11:56:19 -0700 (PDT) Received: by 10.96.136.39 with HTTP; Thu, 12 Mar 2015 11:56:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 11:56:19 -0700 Message-ID: From: Narseo Vallina Rodriguez To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 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:56:50 -0000 >> > 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. > It depends and I'm not sure if we're now on the same page :). Control-plane latency can affect more than you think and the control-plane dynamics can be very complex, including also promotions and demotions between UMTS channels to HS(D/U)PA(+) channels which also increase user-plane latency. The latter case affects more during long flows as a result of fairness policies implemented by the RNC as the number of HSPA channels are limited (each HSPA category has a defined number of channels using TDM). The most common demotion (or inactivity) timeout from DCH to FACH/IDLE is 6 seconds in most mobile operators which is triggered even if a TCP connection is kept alive but no packet was transmitted during this interval. The timeout can be lower for some operators with more aggressive configurations, larger for others more conservative (at the expenses of draining the battery of the phones) or even 0s for operators and handsets supporting "Fast Dormancy". If the handset is demoted, then the next packet will suffer the control plane latency again that is in the order of 1 to 2 seconds depending on signaling congestion at the RNC, SNR, and 3GPP standard. There's a lot of evidence of these dynamics