General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Narseo Vallina Rodriguez <narseo@icsi.berkeley.edu>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] http/2
Date: Sun, 15 Mar 2015 08:23:59 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.02.1503150819040.20507@uplift.swm.pp.se> (raw)
In-Reply-To: <CAJmR=Q=75onWkhb3ZuoCJpAEmwZywU1y3GXSBiy8FWbOkgFbkw@mail.gmail.com>

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

  parent reply	other threads:[~2015-03-15  7:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 21:38 Kartik Agaram
2015-03-12 15:02 ` Jonathan Morton
2015-03-12 18:18   ` Narseo Vallina Rodriguez
2015-03-12 18:39     ` Jonathan Morton
2015-03-12 18:56       ` Narseo Vallina Rodriguez
2015-03-12 19:07         ` Jonathan Morton
2015-03-12 19:28           ` Narseo Vallina Rodriguez
2015-03-12 19:42             ` Jonathan Morton
2015-03-15  7:23         ` Mikael Abrahamsson [this message]
2015-03-12 18:05 ` Rich Brown
2015-03-15  7:13 ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1503150819040.20507@uplift.swm.pp.se \
    --to=swmike@swm.pp.se \
    --cc=bloat@lists.bufferbloat.net \
    --cc=narseo@icsi.berkeley.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox