>[...]
>> Look forward to the day (hopefully real soon) when window-scaling
>> is ubiquitous; As we remember, window-scaling does *not* mean
>> large-windows (it allows it to happen, but the buffer space needs
>> to be allocated on BOTH sides of a connection). Now, imagine:
>>
>> o You want to do something on the Internet that will benefit
>> from large windows (say: transfer size > bandwidth*delay product)
>> o You are clever and *know* that large-windows will be beneficial
>> for you
>> o You make sure that you application (or system defaults) provide your
>> connection to a distant server with enough buffer space to advertise
>> the necessary large window
>> o You manage to establish a connection, and guess what... the server
>> only advertises a window size of 32KB (or something smaller than
>> you need)
>>
>Eric,
>
>I think you've raised what may be the toughest problem to crack here.
>
>If a web server is to be able to support well a delay-bandwidth product of
>two megabytes (a 45 Mbps link with half second round trip time) and if
>the web server is to support 500 simultaneous open TCP connections, it
>would seem that it may need a gigabyte of memory for all the socket buffers.
Ah, but the good (?) news is that Eric's first bullet above comes into
play and renders large windows useless for most Web traffic
anyway. Our recent measurements show that the vast majority of Web
connections are too short to benefit from window scaling and big
socket buffers, regardless of the path. So, performance will still
stink on the long-delay paths, even if the hosts have loads of
RAM. These stats come from measurements on two busy OC-3 trunks:
Web server traffic:
average # packets per flow: 14-20
average kbytes transferred: 9-12
average connection duration: 14-20 secs
Web server traffic as a percentage of the trunk's overall traffic:
50-70% of bytes, 30-35% of packets and flows
Web client traffic:
average # packets per flow: 14-16
average kbytes transferred: 1
average connection duration: 14-20 secs
Web client traffic as a percentage of the trunk's overall traffic:
6-8% of bytes, 30-45% of packets and flows
Greg
----
Gregory J. Miller
vBNS Engineering
MCI Telecommunications
Reston, VA 20191 [email protected]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST