Subject: Proxies and packet loss

From: Peter Lepeska <[email-masked]>
Date: Wed, 5 Mar 2014 12:56:41 +0000

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 5 Mar 2014 08:57:08 -0800

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 <[email-masked]> wrote:

> This draft (
> https://tools.ietf.org/html/draft-white-httpbis-spdy-analysis-00)

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 7 Mar 2014 01:11:32 +0000

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 (陈智昌) <[email-masked]>wrote:

> 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 <[email-masked]>wrote:
>
>> This draft (

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 7 Mar 2014 23:11:08 +0000

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