Re: [tcpm] Increasing the Initial Window - Notes

[Aki Nyrhinen <[e-mail]>]

On Thu, 2010-11-11 at 12:27 +0000, Scheffenegger, Richard wrote:

> Traffic rarely comes in via 1GE, and drops down to a 64kbps bottleneck
> link. Only in the direction homeuser->webserver this huge bandwidth
> disparity might be encountered in a single step (but even then I doubt
> it).

> Web server traffic probably runs over a series of shrinking pipes (ie
> 10G/1G/OC12/OC3/T3/T1/64k) - so in the typical web server environment,
> even if each link has only small buffers, the server->homeuser
> direction will less likely show bad effects I would think. Which
> alignes with the data you presented at ICCSG, correct?

i don't know what is common and what is not, but my understanding is
that here, a dsl access network is typically quite fast optical down to
the dslam, which provides dsl access to large number of customers over
their dedicated coppers. on the dslam you have exactly the dslam
manufacturers default magic number of fifo queuing, which is most likely
64KB or 40 packets regardless of the customer sla. this is likely to be
the first place where queuing occurs after the servers uplink, given the
'valley free' characteristic etc.

cable network has a similar story, the amount of cpe served by a single
cmts is large so cmts will sit in a very fast network, so the queuing
takes place there.

for wwan (gprs, edge, 3g, etc.), my experience of queuing delays
suggests 128KB is typical here (worst case queuing delay beyond 10
seconds at 60kbps).

perhaps modem pools aside, i have yet to see the access network were too
little buffering is a problem.

i have been hoping for quite a while that the buffering would go down to
improve interactive performance during bulk transfers but it just does
not seem to happen so i have given up hope. instead, i have started
hoping they keep the defaults because bandwidths are rising. above
10Mbps, 64KB is quite tolerable.

	Aki