Re: [hybi] SPDY protocol from google frame

[Jamie Lokier <jamie at shareable.org>]

Roberto Peon wrote:
> 
>    All we know that, at Google, we see TCP retransmits which are
>    seemingly indicative of a 1% packet loss rate.
> 
>    One of the things that we're trying to convince people to do is a
>    internet-wide study of packet loss. No-one really has a good model for
>    it. No-one really understands it beyond their little corner of the
>    'net.. and that isn't good enough. For instance, when packet loss
>    occurs, is it truly random? Or is it "correlated" (e.g. if you had 6
>    tcp connections to the same host would they likely all drop packets at
>    the same time). We suspect that it is correlated.. but have no proof.
>    In any case, we'll start real world testing soon-- in the next few
>    weeks (certainly before the end of Q4) we'll have a Chromium
>    dev-channel (i.e. pre-beta) release out as well as some public facing
>    machines at Google. Thus, you'll be able to test against Google soon.
>    Unfortunately, it will likely only be Google for the immediate future
>    :/, though I hope that others will join in the experiment soon.

The places where I've seen the most "might be random" packet loss have
been over mobile IP, getting up to about 5% loss while still being
(barely) usable for web access and SSH sessions.  So don't forget to
run Chromium dev-channel on your phones for testing :-)

Other than that, it's been mostly links or routers going down then
coming up again 10 seconds later, which is of course highly correlated
among multiple connections using the link/route at the time :-)

10 years ago it was (for me) 56k modems over poor quality lines,
behaving with a similar loss and latency profile as what I see for
mobile IP now, but with a much lower ceiling on throughput of course
(56kbps vs. >2Mbps).

>    On Wed, Nov 18, 2009 at 2:23 AM, Thomson, Martin
>    <[1]Martin.Thomson at andrew.com> wrote:
> 
>      The 11% speedup is probably more indicative of real world
>      performance.  I note that 1% packet loss is quite high for the
>      sorts of connections simulated in the tests.  TCP doesn't like
>      those sorts of loss rates, especially for larger payloads.

I regularly see higher loss percentages over a link which is still
working.  On my experience of mobile IP, up to 5% is not uncommon.
They tend to come mixed between vaguely random-looking losses at <2%
loss, to short bursts of loss averaging over time at up to 5%.  (At
higher percentages it's obvious the link is faulty and isn't usable,
but at 5% it continues to be usable, although annoyingly slow,
perhaps due to TCP's behaviour at such high loss rates.)

When loss becomes noticably bursty, I notice that ping responses
following a burst of loss are returned in a burst, with the first
having a high latency - about 5 seconds - and dropping, as if the
responses (or maybe requests) had all been queued up behind a
temporary link blockage of a few seconds, and then sent in rapid
succession.  But there is always some loss when that happens too, it's
not just queuing.

The fact that I see >1% regularly and Martin Thomson does not, just
confirms what Roberto says about loss measurements being confined to
each person's corner of the net.

An important related issue is latency, and latency variability.  I
noticed in the discussions about WebSocket that some people seem to
assume that round-trip latency from clients to web servers is not
significant enough to optimise for, but in my experience it depends
greatly on the type of link being used.  I've measured round-trip
latency over links where I'm having a useful web browsing experience,
ranging from <0.1 milliseconds up to >50 seconds.

-- Jamie