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
next prev 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