From: "H.K. Jerry Chu" <hkjerry.chu@gmail.com>
To: Ed W <lists@wildgooses.com>
Cc: Patrick McManus <mcmanus@ducksong.com>,
David Miller <davem@davemloft.net>,
davidsen@tmr.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: Raise initial congestion window size / speedup slow start?
Date: Fri, 16 Jul 2010 18:23:56 -0700 [thread overview]
Message-ID: <AANLkTimk1TfddBqS8t1iApUNpsic7dZ0zfi9wtkjG82-@mail.gmail.com> (raw)
In-Reply-To: <4C4099D6.6020305@wildgooses.com>
On Fri, Jul 16, 2010 at 10:41 AM, Ed W <lists@wildgooses.com> wrote:
>
>> and while I'm asking for info, can you expand on the conclusion
>> regarding poor cache hit rates for reusing learned cwnds? (ok, I admit I
>> only read the slides.. maybe the paper has more info?)
>>
>
> My guess is that this result is specific to google and their servers?
>
> I guess we can probably stereotype the world into two pools of devices:
>
> 1) Devices in a pool of fast networking, but connected to the rest of the
> world through a relatively slow router
> 2) Devices connected via a high speed network and largely the bottleneck
> device is many hops down the line and well away from us
>
> I'm thinking here 1) client users behind broadband routers, wireless, 3G,
> dialup, etc and 2) public servers that have obviously been deliberately
> placed in locations with high levels of interconnectivity.
>
> I think history information could be more useful for clients in category 1)
> because there is a much higher probability that their most restrictive
> device is one hop away and hence affects all connections and relatively
> occasionally the bottleneck is multiple hops away. For devices in category
> 2) it's much harder because the restriction will usually be lots of hops
> away and effectively you are trying to figure out and cache the speed of
> every ADSL router out there... For sure you can probably figure out how to
> cluster this stuff and say that pool there is 56K dialup, that pool there is
> "broadband", that pool is cell phone, etc, but probably it's hard to do
> better than that?
>
> So my guess is this is why google have had poor results investigating cwnd
> caching?
Actually we have investigated two type of caches, a short-history limited size
internal cache that is subject to some LRU replacement policy hence
much limiting
the cache hit rate, and a long-history external cache, which provides much more
accurate cwnd history per subnet but with high complexity and
deployment headache.
Also we have set out for a much more ambitious goal, to not just speed
up our own
services, but also provide a solution that could benefit the whole web
(see http://code.google.com/speed/index.html). The latter pretty much
precludes a complex
external cache scheme mentioned above.
Jerry
>
> However, I would suggest that whilst it's of little value for the server
> side, it still remains a very interesting idea for the client side and the
> cache hit ratio would seem to be dramatically higher here?
>
>
> I haven't studied the code, but given there is a userspace ability to change
> init cwnd through the IP utility, it would seem likely that relatively
> little coding would now be required to implement some kind of limited cwnd
> caching and experiment with whether this is a valuable addition? I would
> have thought if you are only fiddling with devices behind a broadband router
> then there is little chance of you "crashing the internet" with these kind
> of experiments?
>
> Good luck
>
> Ed W
>
next prev parent reply other threads:[~2010-07-17 1:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4C3D94E3.9080103@wildgooses.com>
[not found] ` <4C3DD5EB.9070908@tmr.com>
2010-07-14 18:15 ` Raise initial congestion window size / speedup slow start? David Miller
2010-07-14 18:48 ` Ed W
2010-07-14 19:10 ` Stephen Hemminger
2010-07-14 21:47 ` Mitchell Erblich
2010-07-14 20:17 ` Rick Jones
2010-07-14 20:39 ` Hagen Paul Pfeifer
2010-07-14 21:55 ` David Miller
2010-07-14 22:13 ` Hagen Paul Pfeifer
2010-07-14 22:19 ` Rick Jones
2010-07-14 22:40 ` Hagen Paul Pfeifer
2010-07-14 22:52 ` Ed W
2010-07-14 23:01 ` Hagen Paul Pfeifer
2010-07-14 23:05 ` Ed W
2010-07-15 3:49 ` Bill Fink
2010-07-15 5:29 ` H.K. Jerry Chu
2010-07-15 19:51 ` Rick Jones
2010-07-15 20:48 ` Stephen Hemminger
2010-07-16 0:23 ` H.K. Jerry Chu
2010-07-16 9:03 ` Hagen Paul Pfeifer
2010-07-15 10:33 ` Alan Cox
2010-07-14 22:05 ` Ed W
2010-07-14 22:36 ` Hagen Paul Pfeifer
2010-07-14 23:01 ` Ed W
2010-07-15 4:12 ` Tom Herbert
2010-07-15 7:48 ` Ed W
2010-07-15 17:36 ` Jerry Chu
2010-07-15 5:09 ` H.K. Jerry Chu
2010-07-15 2:52 ` Bill Fink
2010-07-15 4:51 ` H.K. Jerry Chu
2010-07-16 17:01 ` Patrick McManus
2010-07-16 17:41 ` Ed W
2010-07-17 1:23 ` H.K. Jerry Chu [this message]
2010-07-17 0:36 ` H.K. Jerry Chu
2010-07-19 17:08 ` Rick Jones
2010-07-19 22:51 ` H.K. Jerry Chu
2010-07-19 23:42 ` Hagen Paul Pfeifer
2010-07-15 23:14 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimk1TfddBqS8t1iApUNpsic7dZ0zfi9wtkjG82-@mail.gmail.com \
--to=hkjerry.chu@gmail.com \
--cc=davem@davemloft.net \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@wildgooses.com \
--cc=mcmanus@ducksong.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).