>John Ramsey wrote:

>Surely the whole idea behind TCP "slow start" is to allow the traffic to
>build up gradually to the maximum level the connection acn sustain,
>thereby avoid the "spewing out packets/dropping packets/retransmit"
>scenario.

>It seems inconsistent to me to claim on the one hand that Slow Start
>will limit your throughput for small transfers (which it will), and on
>the other hand to claim that it won't do it's job in congestion control.

Your absolutely correct, slow start finds a sustainable network transfer
rate, conjestion control will clamp to that rate.

The rcvwindow is designed as a signal between the receiving TCP and the
sending TCP, the issue is that rcvwindow can throttle the transfer rate if
(1000/rtt) * rcvwnd is less that available transfer rate. My comment was if
you are going to adjust rcv window then calculate an optimum setting based
on the parameters of the network (e.g. 16k), just setting it to a huge
number has other implications.

For example, if a receiving TCP suddenly runs out of memory, it has no
choice but to close rcvwnd and drop packets until memory comes available.
The sending TCP wont stop sending until it finds out, which is about half a
rtt, this can result in a full window of data being dropped by the receiving
TCP. If you have an 8k rcvwnd then 8k gets dropped, 130k rcvwnd 130k gets
dropped and must be retransmitted. The faster the downlink the higher the
likelyhood that all packets will get dropped before memory becomes
available.

With a rcv window of 130k, there may be 260 512 byte packets in the pipline.
The "could you stop sending please" signal is sent in the ack packet, behind
200 other ack packets that are currently queued on the 33k uplink modem, the
chances of that signal getting to the server before all 260 packets have
arrived by satelite are pretty remote.

The reality is that you can probably only send 60 ack packets a second up
the 33k link which makes it impossible to fill a 130k rcv window anyway. So
when Win98 shuts it's receive window because the user moved their mouse only
about 60k needs to be retransmitted.

My suggestion was that an increase from 8k to 16k rcv window should
eliminate the rcvwnd bottleneck, increasing it to 130k "could" create other
issues, so why bother.

This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to majordomo@unixathome.org
with "unsubscribe adsl" in the body of the message
Received on Fri Dec 15 11:11:45 2000