Re: [Bloat] http/2

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

On 12 Mar 2015 20:18, "Narseo Vallina Rodriguez" <narseo@icsi.berkeley.edu>
wrote:
>
> Hi Jonathan
>
> > 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.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1893 bytes --]