General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Narseo Vallina Rodriguez <narseo@icsi.berkeley.edu>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Kartik Agaram <ak@akkartik.com>,
	Jordan Peacock <hewhocutsdown@gmail.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] http/2
Date: Thu, 12 Mar 2015 11:56:19 -0700	[thread overview]
Message-ID: <CAJmR=Q=75onWkhb3ZuoCJpAEmwZywU1y3GXSBiy8FWbOkgFbkw@mail.gmail.com> (raw)
In-Reply-To: <CAJq5cE2RGNWLtXQEOscXqTteJPioV0GnGkSYkwKk80CBjXCxqQ@mail.gmail.com>

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

  reply	other threads:[~2015-03-12 18:56 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 [this message]
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
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='CAJmR=Q=75onWkhb3ZuoCJpAEmwZywU1y3GXSBiy8FWbOkgFbkw@mail.gmail.com' \
    --to=narseo@icsi.berkeley.edu \
    --cc=ak@akkartik.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=hewhocutsdown@gmail.com \
    /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