Re: Problematic Approaches

From: Tim Shepard ([email protected])
Date: Wed Aug 06 1997 - 17:19:32 EDT


> >You need to add the memory at the bottleneck router, which is not
> >necessarily the uplink router if the satellite link is not bottleneck.
> >(But the adminstrator of the bottleneck router may have no connection
> >with the adminstrator of the satellite link, so this is a problematic
> >approach to solving this problem.)
>
[...]
> 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)
>
> Bummer, despite all your clean living, you're in Pokeyland! :o(
[...]
> Darn! :o)

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.

I wonder how BSD-centric this thinking is. I having a fantasy of a
TCP that just is passed pointers into shared memory holding a cache of
web pages and not having to keep a seperate copy of the data in the
socket send buffers for each and every connection. Hmm...

                        -Tim Shepard
                         BBN Systems and Technologies
                         [email protected]
                         +1 617 873 2013



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:29 EST