Re: [Bloat] http/2

[Narseo Vallina Rodriguez <narseo@icsi.berkeley.edu>]

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