Re: Proxies and packet loss

But also implied in your point is that forward proxies will eventually be
deploying an improved transport (QUIC for instance), which would have
wonderful performance benefits for users. And is one more reason why
improving the proxy discovery mechanism in HTTP/2 (or, more accurately, in
RFCs that follow upon the core spec) is so important. Service providers
(mobile, satellite, and other) could offer their users an immediate
performance boost across all browsers and all content servers if their
proxies deployed a fast transport like QUIC and auto-discovery is well
designed.

Thanks,

Peter


On Fri, Mar 7, 2014 at 1:11 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:

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