> end-to-end performance for small-object web transfers, and time to achieve
> full window state on the network in general.
"General release" users run at modem speeds;
Modem speeds have gone up 4x since 9600 days when wide deployment of TCP
stack was made. Now I know we're in a context of 2400bps->OC3 but down at
the low end, that 4x factor is not insignificant. Sure, MTU hasn't changed,
but I bet the back-end buffering in the link has.
their window is max'd at 1 or 2 anyway.
I think you'll find that even on modem lines, now that 28.8 and above is
ubiquitous, the difference between time to get to a 2-3 window (not 1-2)
from a start of 1, and time to achieve viable transfer if the initial window
is 2-3, does make a difference.
They burn enough time during packet transmission
to adjust to network state.
Not my experience. When I did some crude timings last year, the time to
stabilize transfer rate at the maximum was long enough that sub 16k objects
never got to a full speed transfer. The cache stats suggest that web data
is around a median size of 16k, with enough skew to smaller objects that
for every TCP connection, 3-4 round trips are required to get to full window
in which time an initial full window will have loaded.
If you can shave off 1/3 of the round-trip cost per median object,
isn't that worth it?
HTTP:1.1 persistant/mux is not widely deployed. Lotsa 1.0 parallel loads
out there.
In any case, unless effect of an increase is provably *bad*, Wouldn't this
be a possibly ok thing? Like for those pursaps on Hughes DirecPC where there
is a direct-to-pc satpipe coming in..
Down here, ISP's with inherently assymetric inbound are no longer a
niche. Of the large Australian players, 2 are already on sat mix inbound,
and one is soon to be there, and at least 2 brokers are acting as middle
men for the next ISP tier down. This suggests that for >50% of the dialup
market, their web call is already likely to face a long delay path inbound.
(cache mediated. I'm probably over-stating my case here.)
-George
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST