From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2E4DF21F226 for ; Sun, 15 Mar 2015 00:24:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CF789A1; Sun, 15 Mar 2015 08:23:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1426404239; bh=7iF/ndWJi3UrhwYszBHmHpEZqiq6v5pTybHm8sd6k/k=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WZmkKhdGfJqf8FFOE/ulyakzCYXPs8524q6YqEE7o8Ykm2IBbkqPFVDfIdRzSqFXR s7IKq1335bE19buA7Qh11279YFd/gBooy9hYOfj8iFX4uYOB9uqFsSBRZT4cqOzFp4 6uDtJlxYpx2efkXONwhI8vMyz7pumafeHPm4RB9c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C1CD39F; Sun, 15 Mar 2015 08:23:59 +0100 (CET) Date: Sun, 15 Mar 2015 08:23:59 +0100 (CET) From: Mikael Abrahamsson To: Narseo Vallina Rodriguez In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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: Sun, 15 Mar 2015 07:24:32 -0000 On Thu, 12 Mar 2015, Narseo Vallina Rodriguez wrote: > 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). Ok, I understand you're trying to get this right, however I don't see this as the most probable explanation for the use-case described. Most of the time for this use-case, you'll see the HSPA channels get properly established after approximately 1 second, and they'll stay up until the transfer is done. One RNC vendor I have fairly well knowledge of, would 400 packets of buffering in the GGSN->RNC->eNodeB->Handset direction. I don't know about the others. With half a megabit/s of buffer drain, that means max 10 seconds of buffering if my calculations are correct. There can potentially be buffering in the GGSN/SGSN as well. This is if everything is working perfectly. If there are other problems, the drain rate might be slower than half a megabit/s and this might induce further latency. -- Mikael Abrahamsson email: swmike@swm.pp.se