Re: [squid-users] squid speedup to client using TCP fast start?

On 27/11/10 19:26, Linda Walsh wrote:
>
>
> There's an article pointed to by slashdot @
> http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
> where the author found that instead of a slow start of sending a packet
> or two and waiting for an ACK, some sites like Google and Microsoft,
> optimize for their initial web page display by NOT "slow starting" and
> sending 4 or more packets w/o waiting for the initial ACK. This gives
> them a LARGE boost for that initial page -- and would for any initial
> start of a TCP connection.
>
> Since many connections to squid are small TCP session, it seems

This statement is no longer certain. HTTP/1.1 defauts to longer
connections than HTTP/1.0 to avoid these same TCP delays.

> eliminating the 'slow start' might provide a significant boost when
> loading pages with browsers that use many small TCP connections.

Browsers load a max of 10 connections. With the older HTTP/1.0 Squid
this could result is log as these few connections were opened and closed
on the same client-proxy link. (avoided by turning
client_persistent_connections ON).

>
> Is this something the squid designers have given any consideration to
> for inclusion as an option -- is it something that could be done when
> setting up a connection to a remote server? I.e. when 'fetching', is it
> possible to set the initial window 'larger' -- since most of the benefit
> comes from using a larger window where the RTT is 'large' (~>30ms).

You had best ask those designers... over on the squid-dev mailing list
where they hang out. I'm the only dev that reads this list regularly and
any such decisions were made well before my time in the project.

>
> If the RTT times between the squid cache and the client are very low
> already, then the benefit wouldn't be as noticeable.
>
> Some research papers from presentations on the benefit of increasing the
> initial startup window:
> Abstract:
> http://www.google.com/research/pubs/pub36640.html
> Full Paper:
> http://www.isi.edu/lsam/publications/phttp_tcp_interactions/node2.html
>
> Some simulations from 1998 on the value of increasing the initial TCP
> window size:
> http://www.rfc-archive.org/getrfc.php?rfc=2414
>
> Apparently, a patch may be necessary to give applications control over
> this, this patch was shown here:
> http://www.amailbox.org/mailarchive/linux-netdev/2010/5/26/6278007
>

ICMP, MTU, ECN and Window scaling have only partial support in the IPv4
Internet. When they work things go great. Squid leaves most of this to
the underlying system settings for tuning. Several things like buffers
are handled dynamically from the OS provided information at runtime.

> -----
>
>
> Also another method of speeding up web page delivery has to do with
> HTTP pipelining -- however, some paper (forget the link, had too many
> open and then the window crashed...ARG)...said this wasn't widely used
> due to problems with proxy support.
>
> Doesn't (or does?) squid support this?

Squid supports pipelining since 2.5 or earlier.

The design flaw with pipelines is that if the connection closes for any
reason the entire requests set is lost has to be re-sent by the browser.
There are a great many reasons for closing a TCP link in HTTP/1.0.
Dynamic content of unknown length being the overwhelming cause. So
HTTP/1.1 support is essentially a requirement for reliability on the
pipieline.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3