Re: Proxies and packet loss

Thanks for sending this.

But I question the validity of the test. The test uses 20 connections and
round robins objects on to them via proxy.pac logic. Since the idle period
between page loads kicks TCP back to slow start, it means the first 20
objects of any page are sent over a slow-starting connection. Also, since
their connection selection algorithm is performed by the proxy.pac they
cannot do the "late binding" of requests to fast connections that is
reported as being an important advantage of HTTP over SPDY earlier in the
paper, but is actually an advantage of any connection pool.

The graphs (Figure 9) that show the peak throughput of the HTTP case as
being much higher than single connection SPDY are compelling. A SPDY proxy
that used multiple connections (but far fewer than 20) and late binding
would see that kind of peak throughput and would result in a faster page.

I agree that fixing the transport is the real solution but until then SPDY
proxies should use more than one connection.

Peter




On Wed, Mar 5, 2014 at 4:57 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> While I have lots of caveats about this paper (which I haven't written up
> yet), I think it correctly identifies that multiple connections are not the
> solution: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf.
> See section 6.1. The real solution is to fix the transport.
>
>
> On Wed, Mar 5, 2014 at 4:56 AM, Peter Lepeska <bizzbyster@gmail.com>wrote:
>
>> This draft (
>> https://tools.ietf.org/html/draft-white-httpbis-spdy-analysis-00)
>> documents that there is a "fairly significant performance loss with SPDY"
>> in tests that introduced packet loss. The primary reason for this is that
>> fewer TCP connections are used so a single packet drop reduces bandwidth
>> for a greater % of the traffic at any given time.
>>
>> I fear that this effect will be still worse when browsers are using a
>> single TCP connection to a SDPY (or HTTP/2) proxy when accessing multi-host
>> sites and that therefore we may want to make specific recommendations about
>> multiple TCP connection use when talking to explicit proxies.
>>
>> I'm not sure this is something that should be mentioned in the core spec
>> (and discussed as part of open issue #413 on proxies) but perhaps in a
>> follow-on specification dedicated to proxy use in HTTP/2 -- maybe built on
>> Mark's proxy draft?
>> http://tools.ietf.org/id/draft-nottingham-http-proxy-problem-00.txt.
>>
>> I'm happy to help out on such a proxy spec if it's something the group
>> would like to take on.
>>
>> Thanks,
>>
>> Peter
>>
>
>